Everyone's suggestions feel designed to frustrate me. Instructions on how to cajole and plead that seem more astrology than engineering.

This is the pattern I settled on about a year ago. I use it as a rubber-duck / conversation partner for bigger picture issues. I'll run my code through it as a sanity "pre-check" before a pr review. And I mapped autocomplete to ctrl-; in vim so I only bring it up when I need it.

Otherwise, I write everything myself. AI written code never felt safe. It adds velocity but velocity early on always steals speed from the future. That's been the case for languages, for frameworks, for libraries, it's no different for AI.

In other words, you get better at using AI for programming by recognizing where its strengths lie and going all in on those strengths. Don't twist up in knots trying to get it to do decently what you can already do well yourself.

Hey, Boris from the Claude Code team here. A few tips:

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!

  > I add to my team’s CLAUDE.md multiple times a week.

  @AGENTS.md

Using voice transcription is nice for fully expressing what you want, so the model doesn't need to make guesses. I'm often voicing 500-word prompts. If you talk in a winding way that looks awkward when in text, that's fine. The model will almost certainly be able to tell what you mean. Using voice-to-text is my biggest suggestion for people who want to use AI for programming

(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

Soft plug: take a look at https://github.com/tilework-tech/nori-profiles

I've spent the last ~4 months figuring out how to make coding agents better, and it's really paid off. The configs at the link above make claude code significantly better, passively. It's a one-shot install, and it may just be able to one-shot your problem, because it does the hard work of 'knowing how to use the agents' for you. Would love to know if you try it out and have any feedback.

(In case anyone is curious, I wrote about these configs and how they work here: https://12gramsofcarbon.com/p/averaging-10-prs-a-day-with-cl...

and I used those configs to get to the top of HN with SpaceJam here: https://news.ycombinator.com/item?id=46193412)

what really got me moving was dusting off some old text about cognitive styles and team work. Learning to treat agents like a new team-member with extreme tendencies. Learning to observe both my practices and the agents' in order to understand one another's strengths and weaknesses, indicating how we might work better together.

I think this perspective also goes a long way to understanding the very different results different devs get from these tools.

my main approach to quality is to focus agent power on all that code which I do not care about the beauty of: problems with verifiable solutions, experiments, disposable computation. eg my current projects are build/deploy tools, and I need sample projects to build/deploy. I never even reviewed the sample projects' code: so long as they hit the points we are testing.

svelte does not really resonate with me, so I don't know it well, but I suspect there should be good opportunities for TDD in this rewrite. not the project unit tests, just disposable test scripts that guide and constrain new dev work.

you are right to notice that it is not working for you, and at this stage sometimes the correct way to get in sync with the agents is to start again, without previous missteps to poison the workspace. There's good advice in this thread, you might like to experiment with good advice on a clean slate.

Here’s how I would do this task with cursor, especially if there are more routes.

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 see LLMs as searchers with the ability to change the data a little and stay in a valid space. If you think of them like searchers, it becomes automatic to make the search easy (small context, small precise questions), and you won't keep trying again and again if the code isn't working(no data in the training). Also, you will realize that if a language is not well represented in the training data, they may not work well.

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

My favorite set of tools to use with Claude Code right now: https://github.com/obra/superpowers

1. Start with the ‘brainstorm’ session where you explain your feature or the task that you're trying to complete. 2. Allow it to write up a design doc, then an implementation plan - both saved to disk - by asking you multiple clarifying questions. Feel free to use voice transcription for this because it is probably as good as typing, if not better. 3. Open up a new Claude window and then use a git worktree with the Execute Plan command. This will essentially build out in multiple steps, committing after about three tasks. What I like to do is to have it review its work after three tasks as well so that you get easier code review and have a little bit more confidence that it's doing what you want it to do.

Overall, this hasn't really failed me yet and I've been using it now for two weeks and I've used about, I don't know, somewhere in the range of 10 million tokens this week alone.

AI programming, for me, is just a few simple rules:

1. True vibe coding (one-shot, non-trivial, push to master) does not work. Do not try it.

2. Break your task into verifiable chunks. Work with Claude to this end.

3. Put the entire plan into a Markdown file; it should be as concise as possible. You need a summary of the task; individual problems to solve; references to files and symbols in the source code; a work list, separated by verification points. Seriously, less is more.

4. Then, just loop: Start a new session. Ask it to implement the next phase. Read the code, ask for tweaks. Commit when you're happy.

Seriously, that's it. Anything more than that is roleplaying. Anything less is not engineering. Keep a list in the Markdown file of amendments; if it keeps messing the same thing up, add one line to the list.

To hammer home the most important pieces:

- Less is more. LLMs are at their best with a fresh context window. Keep one file. Something between 500 and 750 words (checking a recent one, I have 555 words / 4276 characters). If that's not sufficient, the task is too big.

- Verifiable chunks. It must be verifiable. There is no other way. It could be unit tests; print statements; a tmux session. But it must be verifiable.

I've had one situation in which I was able to get a 20X productivity boost. I needed to do a large number of similarish things. I carefully hand coded one, created an AGENTS.md that explained everything in a lot of detail and then went to town on generation.

Everything went well and I knew what to expect so reviewing the code was quick.

The experience was super great. I was a 20X AI boosted engineer for a bit. But, I haven't had that situation again.

Anyway, I would say, try to find areas of the code that fit this model if you can. AI is phenomenal for this use case.

First you have to be very specific with what you mean by idiomatic code - what’s idiomatic for you is not idiomatic for an LLM. Personally I would approach it like this:

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).

The suggestions are really all over the place. Feels AI.

This may sound strange but here is how I define my flow.

1. Switch off your computer.

2. Go to a nice Park.

3. Open notebook and pen, and write prompts that are 6-8 lines long on what task you want to achieve, use phone to google specific libraries.

4. Come back to your PC, type those prompts in with Plan mode and ask for exact code changes claude is going to make.

5. Review and push PR.

6. Wait for your job to be automated.

I've found success using the following process:

1. get the LLM to generate a spec from the code (the spec is your new source code). Take your time here, make sure it is correct. Split out implementation details unless they are critical to the business logic.

2. Using the spec, begin crafting an ARCHITECTURE.md -- you put all your non-critical implementation details here. If you need to track requirements, require the LLM to reference the paragraph number(s) of the spec file as it writes the architectural spec. Take your time here as well (this is the second layer of your new source code).

3. Create a high level TODO from the architecture doc.

4. Create a mid-level TODO from the architecture doc (you'll know if this is necessary, perhaps chunk work up by function, feature, or architectural layer).

5. Create a granular level TODO where each task is very tight in scope (write this function, create a translator for this JSON de-serializer to create the app-level model for this object, etc.)

Then let a model go to town.

In the mean-time, you should also require testing. If you have the opportunity, you should have an LLM inspect, spec, and write comprehensive tests for the old code on the external API/interface. You'll be able to use this to test your new implementation to ensure all the corner cases and functionality are covered.

I use AI at work. We have a huge codebase in Golang.

1000s of files.

I had tried cursor, claude code, gemini cli, openai codex and all sorts of vscode based idea (like windsurf, antigravity etc). All of them get overwhelmed when there is something to implement or change in the codebase primarily due to the amount of code.

But I like aider. I had better capabilities and is controllable, you can try. And if you use it with latest claude sonnet or gemini 2.5 pro it will be most accurate. Adding files is a manual process but it has nearly 100% code accuracy.

And it will never change anything without your knowledge.

You can try it.

You should make sure that your queries to the agent contain a "loop condition"[1]. This can be something like "keep trying until yarn test passes".

Always remember that these agents are just LLMs running tools in a loop and treat them as such.

[1] https://www.skeptrune.com/posts/prompting-the-agent-loop/

You know when Claude Code for Terminal starts scroll-looping and doom-scrolling through the entire conversation in an uninterruptible fashion? Just try reading as much as of it as you can. It strengthens your ability to read code in an instant and keeps you alert. And if people watch you pretend to understand your screen, it makes you look like a mentat.

It’s actually a feature, not a bug.

About Svelte, on the svelte subreddit it was reported that GPT 5.2 is better at Svelte, perhaps because it has a more recent knowledge cutoff

But anyway you should set up the Svelte MCP

For me what vastly improved the usefulness when working with big json responses was to install jq in my system and tell the llm to use jq to explore the json, instead of just trying to ingest it all together. For other things I explicitly ask it to write a script to achieve something instead of doing it directly.

I have never once said "Go build feature x" and let it run off. Not saying you do, but I feel like this is how a lot of people interact with these tools. I have a very conversational style of building with these tools, and I'm very blunt with them when I think they're wrong, since I'm fairly experienced and I can smell when something is seemingly wrong with the model's thinking.

I typically have a discussion about how I want the architecture to be and my exact desired end state. I make the model repeat back to me what I want and have it produce the plan to the degree I am happy with. I typically do not have it work in building large amorphous systems, I work with and have it plan subsystems of the overall system I'm building.

A lot of my discussion with the model is tradeoffs on the structure I'm imagining and methods it might know. My favorite sentence to send Claude right now "Is go google this." because I almost never take its first suggested response at face value.

I also watch every change and cancel and redirect ones I do not like. I read code very fast and like the oversight, because even small stupidities stack up.

The workflow is highly iterative and I make changes frequently, my non AI workflow was like this too. Write, compile, test, tweak and repeat.

I like this workflow a lot because I feel I am able to express my designs succinctly and get to a place I'm happy with with much less writing than a lot of the actual code itself which in many cases is not an interesting problem, but work that needs to happen for a working system at all.

I do wind up taking over, but feel less than I used to, in edges where its clear there is not a lot of training data or I'm working on something fairly novel or lower level.

I work in Python, Rust and Typescript (Rust by far most often) and the majority of my work is technically challenging but at the systems design level maybe not low level systems programming challenging. Think high concurrency systems and data processing, training models, and some web dev.

How did you learn how to use AI for coding? I'm open to the idea that a lot of "software carpentry" tasks (moving/renaming files, basic data analysis, etc) can be done with AI to free up time for higher level analysis, but I have no idea where to begin -- my focus many years ago was privacy, so I lean towards doing everything locally or hosted on a server I control so I lack a lot of knowledge of "the cloud" my HN betheren have.

I have a whole workflow for coding with agents.

Get very good at context management (updating AGENTS.md, starting new session, etc).

Embrace TDD. It might have been annoying when Extreme Programming came out 25 years ago, but now that agents can type a lot faster than us, it's an awesome tool for putting guardrails around the agent.

(I teach workshops on best practices for agentic coding)

For this particular project I suggest manually prying one section of the app, committing that change, and then telling Claude "look at commit HASH first, now port feature X in the same style".

Consider giving Cursor a try. I personally like the entire UI/UX, their agent has good context, and the entire experience overall is just great. The team has done a phenomenal job. Your workflow could look something like this:

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.

get out of the way, maybe?

before getting into any implementation, i'd get claude to read and document the starting code, and propose its own idiomatic way to rewrite it to svelte. this is a good use for plan mode, and also a spot where you could walk through with claude to put documentation examples of what you consider good and bad, so it can monkey-see, monkey do.

the other thing that makes it go brrrr is to add lots of feedback loops. unit tests, e2e tests, linters, etc. make sure it can pass everything before it shows you anything.

my overall process would be to

1. go through plan mode for documentation and test writing

2. have claude lay out the plan into steps

3. project setup for builds/feedback loops, deploys, etc

4. for each step in that plan, run back through plan mode to clear up any confusions for the component (also record those in docs) and then let it rip on implementation until its ready for a commit.

claude might take a long time writing the code between qna sessions, but it can all be async so the 15-20min doesnt matter much

Here are some SvelteKit helpers to shove in your agents.md: https://www.davis7.sh/sv

There are a number of ways to get examples into the LLM. I use shadcn-svelte and bitsui and try to copy the examples (copy button at the top of the docs) or tell the LLM to fetch docs from the github repo or use context7's MCP for docs.

Try specification-driven-development with something like speckit [0]. It helps tremendously for facilitating a process around gathering requirements, doing research, planning, breaking into tasks, and finally implementing. Much better than having a coding agent just go straight to coding.

[0] - https://github.com/github/spec-kit

Go into planning mode and plan the overall refactor. Try to break the tasks down into things that you think will fit into a single context window.

For mid sized tasks and up, architecture absolutely has to be done up front in planning mode. You can ask it questions like "what are some alternatives?", "which approach is better?".

If it's producing spaghetti code, can you explain exactly what it's doing wrong? If you have an idea of what ideal solution should look like, it's not too difficult to guide the LLM to it.

In your prompt files, include bad and good examples. I have prompt files for API/interface design, comment writing, testing, etc. Some topics I split into multiple files like criteria for testing, testing conventions.

I've found the prompts where they go "you are a X engineer specializing in Y" don't really do much. You have to break things down into concrete instructions.

Claude has been miserable for anything Java related, in my experience. Use it maybe as a cross check for ChatGPT, which is far superior. They both make mistakes, but Claude repeatedly changes course, contradicts itself, or makes suggestions that are basically unusable. I don't understand why conversations here are always focusing on a bad LLM.

I break everything down into very small tasks. Always ask it to plan how it will do it. Make sure to review the plan and spot mistakes. Then only ask it to do one step at a time so you can control the whole process. This workflow works well enough as long as you're not trying to do anything too interesting. Anything which is even a little bit unique it fails to do very well.

Go slowly. Shoot for a 10% efficiency improvement, not 10x. Go through things as thoroughly as if writing by hand, and don't sacrifice quality for speed. Be aware of when it's confidently taking you down a convoluted path and confidently making up reasons to do so. Always have your skeptic hat on. If something seems off, it probably is. When in doubt, exit the session and start over.

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.

I use Claude. It's really good, but you should try to use it as Boris suggests. The other thing I do is give it very careful and precisely worded specs for what you want it to do. I have the habit, born from long experience, of never assuming that junior programmers will know what you want the program to do unless you make it explicit. Claude is the same. LLM code generators are terrific, but they can't second guess unclear communication.

Using carefully written specs, I've found Claude will produce flawless code for quite complex problems. It's magic.

The approach I’ve been taking lately with general AI development:

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.

If anyone knew the answer to this question, Anthropic would be profitable.

Currently they project they might break even in 2028.

That means that right now, every time you ask an AI a question, someone loses money.

That of course means no-one knows if you can get better at AI programming, and the answer may be "you can't."

Only time will tell.

Lots of good suggestions. However for Svelte in particular I’ve had a lot of trouble. You can get good results as long as you don’t care about runes and Svelte 5. It’s too new, and there’s too much good Svelte code out there used in training that doesn’t use Svelte 5. If you want AI generated Svelte code, restricting yourself to <5 is going to improve your results.

(YMMV: this was my experience as of three or four months ago)

The key insight most people miss: AI isn't a code generator, it's a thinking partner. Start by defining the problem precisely in plain English before asking it to code. Use it for refactoring and explaining existing code rather than generating from scratch. That's where you get the 10x gains.

Also, treat bad AI suggestions as learning opportunities - understand why the code is wrong and what it misunderstood about your requirements.

A largely undiscussed part of AI use in code is that it's actually neither easy nor intuitive to learn max effectiveness of your AI output.

I think there's a lot of value in using AIs that are dumb to learn what they fail at. The methods I learned using gpt3.5 for daily work still transaltes over to the most modern of AI work. It's easy to understand what makes AI fail on a function or two than understanding that across entire projects.

My main tips:

1. More input == lower quality

Simply put, the more you can focus your input data to output results the higher quality you will get.

For example on very difficult problems I will not only remove all comments but I will also remove all unrelated code and manually insert it for maximum focus.

Another way to describe this is compute over problem space. You are capped in compute so you must control your problem space.

2. AI output is a reflection of input tokens and therefore yourself.

If you don't know what you're doing in a project or are mentally "lazy" AI will fail with death by a thousand cuts. The absolute best use of AI is knowing EXACTLY what you want and describing it in as few words as possible. I directly notice if I feel lazy or tired in a day and rely heavily on the model I will often have to revert entire days of work due to terrible design.

3. Every bad step of results from an AI or your own design compound problems as you continue.

It's very difficult to know the limits of current AI methods. You should not be afraid of reverting and removing large amounts of work. If you find it failing heavily repeatedly this is a good sign your design is bad or asking too much from it. Continuing on that path reduces quality. You could end up in the circular debugging loops with every fix or update adds even more problems. It's far better practice to drop the entire feature of updates and restart with smaller step by step actions.

4. Trust AI output like you would stack overflow response or a medium article.

Maybe its output would work in some way but it has a good chance of not working for you. Repeatedly asking same questions differently or different angles is very helpful. The same way debugging via stack overflow was trying multiple suggestions to discover the best real problem.

Start with a problem. I'm building https://helppet.ai, a voice agent for Veterinarians. I didn't know anything about AI programming other than absolute fundamentals I learned in 2017 through Stanford AI course - this was just theory and a lot has changed. I followed startups doing solving similar problems, and I asked detailed questions to everyone I could. I went to AI hack events to learn techniques others are using. Eventually I ended up with something pretty great and had fun doing so. So start with a problem and then work backwards.

Get better at reviewing code

I’ve been doing a rewrite of some file import type stuff, using a new common data model for storage, and I’ve taken to basically pasting in the old code, commented out and telling it to fill the new object using the commented out content as a guide. This probably got me 80% of the way? Not perfect, but I don’t think anything really is.

I find all AI code to be lower quality than humans who care about quality. This might be ok, I think the assumpt with AI is that we don't need to look at code so that it looks beautiful because AI will look at it .

I am probably going to get downvoted to oblivion for this but if you’re going to have AI write your code, you’ll get the most mileage out of letting it do its thing and building tests to make sure everything works. Don’t look at the code it generates - it’s gonna be ugly. Your job is to make sure it does what it’s supposed to. If there’s a bug, tell it what’s wrong and to fix the bug. Let it wade through its own crap - that’s not your tech debt. This is a new paradigm. No one is going to be writing code anymore, just almost like no one is checking the assembly output of a compiler anymore.

This is just my experience. I’ve come to the conclusion that if I try to get AI to write code that works and is elegant, or if I’m working inside the same codebase that AI is adding cruft to, I don’t get much of a speed up. Only when I avoid opening up a file of code myself and let AI do its thing do I get the 10x speed up.

The hack for sveltekit specifically, is to first have Claude translate the existing code into a next.js route with react components. Run it, debug and tweak it. Then have Claude translate the next.js and react components into sveltekit/svelte. Try and keep it in a single file for as long as possible and only split it out once it's working.

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

Its super frustrating there is no official guide. I hear lots of suggestions all the time and who knows if they help or not. The best one recently is tell the LLM to "act like a senior dev", surely that is expected by default? Crazy times.

Planning! I actually prefer DIY planning prompt + docs, not planning mode. Wrote this article about it today actually: https://0thernet.substack.com/p/velocity-coding

I find Claude Code works best when given a highly specific and scoped tasks. Even then sometimes you'll need to course correct it once you notice its going off course.

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.

I did a similar thing.

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

I wrote about my experience from the last year. Hope you find this helpful

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

I think you shouldn't think so much about it, the more you use it, the better you will understand how it can help you. The most gain will be coming from the models jumping and how you get updated using the best for your use case.

Did you use the /init command in Claude Code at the start?

That builds the main claude.md file. If you don’t have that file CC starts each new session completely oblivious to your project like a blank slate.

I learned the hard way, when Claude has 2 conflicting information in Claude.md it tends to ignore both. So, precise language is key, don't use terms like 'object', which may have different meanings in different fields.

I like to followup with "Does this make sense?" or similar. This gets it to restate the problem in its own words, which not only shows you what its understanding of the problem is, it also seems to help reinforce the prompt.

Would love to hear any feedback using Google's anitgravity from a clean slate. Holiday shutdown is about to start at my job and I want to tinker with something that I have not even started.

Honestly if your boss does not force you to use AI, don't.

Don't feel like you might get "left behind". LLM assisted development is still changing rapidly. What was best practice 6 months ago is irrelevant today. By being an early adopter you will just learn useless workarounds that might soon not be necessary to know.

On the other hand if you keep coding "by hand" will keep your skills sharp. You will protect yourself against the negative mental effects of using LLMs like skill decline, general decline of mental capacity, danger of developing psychosis because of the sycophantic nature of LLMs and so on.

LLM based coding tools are only getting easier to use and if you actually know how to code and know software architecture you will able to easily integrate LLM based workflows and deliver far superior results compared to someone who spend their years vibe coding, even if you picked up Claude Code or whatever just a month ago. No need for FOMO,

Don’t!

walk into the woods and never touch a computer again

Automated code checks. Either custom linter rules (like ESLint) or prebuild scripts to enforce whatever architectural or style rules you want, basically all of the stuff that you'd normally flag in code review that can be codified into an automatic check but hasn't been before due to developers either not finding it worth their time to do it, or not having enough time or skill to do that - use the AI to write as many of these as needed, just like:

  node prebuild/prebuild.cjs

which will then run all the other checks you've defined like:

  prebuild/ensure-router-routes-reference-views-not-regular-components.cjs
  prebuild/ensure-custom-components-used-instead-of-plain-html.cjs
  prebuild/ensure-branded-colors-used-instead-of-tailwind-ones.cjs
  prebuild/ensure-eslint-disable-rules-have-explanations.cjs
  prebuild/ensure-no-unused-translation-strings-present.cjs
  prebuild/ensure-pinia-stores-use-setup-store-format.cjs
  prebuild/ensure-resources-only-called-in-pinia-stores.cjs
  prebuild/ensure-api-client-only-imported-in-resource-files.cjs
  prebuild/ensure-component-import-name-matches-filename.cjs
  prebuild/disallow-deep-component-nesting.cjs
  prebuild/disallow-long-source-files.cjs
  prebuild/disallow-todo-comments-without-jira-issue.cjs
  ...

and so on. You might have tens of these over the years of working on a project, plus you can write them for most things that you'd conceivably want in "good code". Examples above are closer to a Vue codebase but the same principles apply to most other types of projects out there - many of those would already be served by something like ESLint (you probably want the recommended preset for whatever ruleset exists for the stack you work with), some you'll definitely want to write yourself. And that is useful regardless of whether you even use AI or not, so that by the time code is seen by the person doing the review, hopefully all of those checks already pass.

If "good code" is far too nebulous of a term to codify like that, then you have a way different and frankly more complex problem on your hands. If there is stuff that the AI constantly gets wrong, you can use CLAUDE.md as suggested elsewhere or even better - add prebuild script rules specifically for it.

Also, a tech stack with typing helps a bunch - making wrong code harder to even compile/deploy. Like, with TypeScript you get npm run type-check (tsc) and that's frankly lovely to be able to do, before you even start thinking about test coverage. Ofc you still should have tests that check the functionality of what you've made too, as usual.

Try a free and open-source VS Code plugin "Code Web Chat".

I want to say a lot of mean things, because an extremely shitty, useless, clearly Claude-generated test suite passed the team PR review this week, tests were useless, so useless the code they were linked to (can't say if the code itself was Ai-written though) had a race condition, that, if triggered and used correctly, could probably rewrite the last entry of any of the firewall we manage (DENY ALL is the one I'm afraid about).

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.

For your task, instead of a direct translation, try adding a "distillation" step in between. Have it take the raw format and distill the important parts to yaml or whatever, then take the distillation and translate that into the new format. That way you can muck with the yaml by hand before translating it back, which should make it easier to keep the intent without the spaghetti getting in the way. Then you can hand-wire any "complexities" into the resulting new code by hand, avoiding the slop it would more likely create.

It may even be worth having it write a parser/evaluator that does these steps in a deterministic fashion. Probably won't work, but maybe worth a shot. So long as it does each translation as a separate step, maybe at least one of them will end up working well enough, and that'll be a huge time saver for that particular task.

I've been heavily vibe coding for a couple of personal projects. A free kids typing game and bringing back a multiplayer game I played a lot as a kid back to life both with pretty good success.

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.

first off, drop the idea of coding "agents" entirely. semi-async death valley is not worth it, you will never get into the flow state with an "agent" that takes less than an hour to spin, and we did not learn how to make true async agents that run for this long while maintaining coherence yet. OpenAI is the closest in that regard, but they are still at a 20-minute mark, so I am not dropping the quotes for now.

another argument against letting LLM do the bulk of the job is that they output code that's already legacy, and you want to avoid tech debt. for example, Gemini still thinks that Kotlin 2.2 is not out, hence misses out on context parameters and latest Swift interoperability goodies. you, a human being, are the only one who will ever have the privilege of learning "at test time", without separate training process.

replace coding "agents" with search tools. they are still non-deterministic, but hey, both Perplexity and Google AI Mode are good at quick lookup of SvelteKit idioms and whatnot. plus, good old Lighthouse can point out a11y issues - most of them stem from non-semantic HTML. but if you really want to do it without leaving a terminal, I can recommend Gemini CLI with some search-specific prompting. it's the only CLI "agent" that has access to the web search to my knowledge. it's slower than Perplexity or even ChatGPT Search, but you can attach anything as a context.

this is the true skill of "how to use AI" - only use it where it's worth it. and let's be real, if Google Search was not filled with SEO crap, we would not need LLMs.

I will be crucified by this, but I think you are doing it wrong.

I would split it in 2 steps.

First, just move it to svelte, maintain the same functionality and ideally wrap it into some tests. As mentioned you want something that can be used as pass/no-pass filter. As in yes, the code did not change the functionality.

Then, apply another pass from Svelte bad quality to Svelte good quality. Here the trick is that "good quality" is quite different and subjective. I found the models not quite able to grasp what "good quality" means in a codebase.

For the second pass, ideally you would feed an example of good modules in your codebase to follow and a description of what you think it is important.

Ask people to do things for you. Then you will learn how to work with something/someone who has faults but can overall be useful if you know how to view the interaction.

This isn't exactly an answer to your question but I've experienced some efficiency gains in using AI agents for pre-reviewing my PRs and getting it to create tests.

You still get to maintain the core code and maintain understandability but it helps with the tasks the take time that aren't super interesting.

There are very real limitations on AI coders in their current state. They simply do not produce great code most of the time. I have to review every line that it generates.

Follow and learn from peopel on youtube who formerly had the same skill level as you did now.

AI is great at pattern matching. Set up project instructions that give several examples of old code, new code and detailed explanations of choices made. Also add a negative prompt, a list of things you do not want AI to do based on past frustrations.

dont forget to include "pls don't make mistakes"

Voice prompts, restate what you want, how you want it from multiple vantage points. Each one is a light cone in a high dimensional space, your answer lies in their intersection.

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.

In addition to what the sibling commenters are saying: Set up guardrails for what you expect in your project's documentation. What is the agent allowed to do when writing unit tests vs say functional tests, what packages it should never use, coding and style templates etc.

1. Introduce it to the code base (tell it: we're going to work on this project, project does X is written in language Y). Ask it to look at the project to familiarize.

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.

> prompting just isn't able to get AI's code quality within 90% of what I'd write by hand

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.

> This kind of work seems like a great use case for AI assisted programming

Always check your assumptions!

You might be thinking of it as a good task because it seems like some kind of translation of words from one language to another, and that's one of the classes of language transformations that LLM's can do a better job at than any prior automated tool.

And when we're talking about an LLM translating the gist of some English prose to French, for a human to critically interpret in an informal setting (i.e not something like diplomacy or law or poetry), it can work pretty well. LLM's introduce errors when doing this kind of thing, but the broader context of how the target prose is being used is very forgiving to those kinds of errors. The human reader can generally discount what doesn't make sense, redundancy across statements of the prose can reduce ambiguity or give insight to intent, the reader may be able to interactively probe for clarifications or validations, the stakes are intentionally low, etc

And for some kinds of code-to-code transforms, code-focused LLM's can make this work okay too. But here, you need a broader context that's either very forgiving (like the prose translation) or that's automatically verifiable, so that the LLM can work its way to the right transform through iteration.

But the transform you're trying to do doesn't easily satisfy either of those contexts. You have very strict structural, layout, and design expectations that you want to replicate in the later work and even small "mistranslations" will be visually or sometimes even functionally intolerable. And without something like a graphic or DOM snapshot to verify the output with, you can't aim for the iterative approach very effectively.

TLDR; what you're trying to do is not inherently a great use case. It's actually a poor one that can maybe be made workable through expert handling of the tool. That's why you've been finding it difficult and unnatural.

If your ultimate goal is to improve your expertise with LLM's so that you can apply them to challenging use cases like this, then it's a good learning opportunity for you and a lot of the advice in other comments is great. The most key factor being to have some kind of test goal that the tool can use for verify its work until it strikes gold.

On the other hand, if your ultimate goal is to just get your rewrite done efficiently and its not an enormous volume of code, you probably just want to do it yourself or find one of our many now-underemployed humans to help you. Without expertise that you don't yet have, and some non-trivial overhead of preparatory labor (for making verification targets), the tool is not well-suited to the work.

Hey, I am bgwalter from the anti-AI industrial complex, which is a $10 trillion industry with a strong lobby in DC.

I would advise you to use Natural Intelligence, which will be in higher demand after the bubble has burst completely (first steps were achieved by Oracle this week).

[dead]

You can using a single simple step: don't

The more you use IA, the more your abilities decreases, the less you are able to use IA

This is the law of cheese: the more cheese, the more holes; The more holes, the less cheese; Thus, the more cheese, the less cheese;

[dead]

[dead]

[dead]

[dead]