[HN Gopher] Ask HN: How can I get better at using AI for program...
___________________________________________________________________
Ask HN: How can I get better at using AI for programming?
I've been working on a personal project recently, rewriting an old
jQuery + Django project into SvelteKit. The main work is
translating the UI templates into idiomatic SvelteKit while
maintaining the original styling. This includes things like using
semantic HTML instead of div-spamming, not wrapping divs in divs in
divs, and replacing bootstrap with minimal tailwind. It also
includes some logic refactors, to maintain the original
functionality but rewritten to avoid years of code debt. Things
like replacing templates using boolean flags for multiple views
with composable Svelte components. 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. This kind of work seems like a great use case for AI
assisted programming, but I've failed to use it effectively. At
most, I can only get Claude Code to recreate some slightly less
spaghetti code in Svelte. Simple prompting just isn't able to get
AI's code quality within 90% of what I'd write by hand. Ideally, AI
could get it's code to something I could review manually in 15-20
minutes, which would massively speed up the time spent on this
project (right now it takes me 1-2 hours to properly translate a
route). Do you guys have tips or suggestions on how to improve my
efficiency and code quality with AI?
Author : lemonlime227
Score : 149 points
Date : 2025-12-13 15:37 UTC (7 hours ago)
| realberkeaslan wrote:
| 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.
| kamikazeturtles wrote:
| How does Cursor compare to Claude Code or Codex?
| jes5199 wrote:
| Cursor makes it easier to watch what the model is doing and
| to also make edits at the same time. I find it useful at work
| where I need to be able to justify every change in a code
| review. It's also great for getting a feel for what the
| models are capable of - like, using Cursor for a few months
| make it easier to use Claude Code effectively
| listic wrote:
| For the one disinclined to get into closed source, proprietary
| tools, what is the next best thing to try?
|
| I heard of Cline and Aider, but didn't try anything.
| rdrd wrote:
| 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).
| XenophileJKO wrote:
| With the current generation of model, it really isn't necessary
| to restart every time you don't like something. Certainly this
| depends on the model. Most of my recent experience is with
| Claude Sonnet/Opus and Gpt-5.x.
|
| I very often, when reviewing code, think of better abstractions
| or enhancements and just continue asking for refactors inline.
| Very very rarely does the model fall off the rails.
|
| I suppose if your unit of work was very large you might have
| more issues perhaps? Generally though, large units of work have
| other issues as well.
| rdrd wrote:
| Yes I too have found newer models (mostly Opus) to be much
| better at iterative development. With that being said if I
| have very strong architectural/developmental steer on what I
| believe the output should be [mostly for production code
| where I thoroughly review absolute everything] it's better to
| have a documented spec with everything covered rather than
| trying to clean up via an agent conversation. In the team I'm
| in we keep all plan.mds for a feature, previously before AI
| tooling we created/revised these plans in Confluence, so to
| some degree reworking the plan is more an artefact of the
| previous process and not necessarily a best practice I don't
| think.
| XenophileJKO wrote:
| Understandable. Certainly my style is not applicable to
| everyone. I tend to "grow" my software more organically.
| Usually because the more optimal structure isn't evident
| until you are actually looking at how all the contracts fit
| together or what dependencies are needed. So adding a lot
| of plan/documentation just slows me down.
|
| I tend to create a very high level plan, then code systems,
| then document the resulting structure if I need
| documentation.
|
| This works well for very iterative development where I'm
| changing contracts as I realize the weak point of the
| current setup.
|
| For example, I was using inheritence for specialized
| payloads in a pipeline, then realized if I wanted to attach
| policies/behaviours to them as they flow through the
| pipeline, I was better off just changing the whole thing to
| a payload with bag of attached aspects.
|
| Often those designs are not obvious when making the initial
| architectural plan. So I approach development using AI in
| much the same way: Generate code, review, think, request
| revision, repeat.
|
| This really only applies when establishing architecturs
| though, which is generally the hardest part. Once you have
| an example, then you can mostly one-shot new instances or
| minor enhancements.
| Alan01252 wrote:
| 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.
| Esophagus4 wrote:
| > 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.
|
| This would have been my tip, as well.
|
| Talk to others who are good with these tools to learn from what
| they're doing and read blogs/docs/HN for ideas, but most
| importantly, make time for yourself on a
| daily/weekly/monthly/whatever basis to practice with the tool.
|
| It's taken me about a year of consistent practice to feel
| comfortable with LLM coding. It just takes time, like learning
| any other technology.
| 8cvor6j844qw_d6 wrote:
| 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.
| mirsadm wrote:
| 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.
| kgwxd wrote:
| sounds like you're doing all the actual work. why not just type
| the code as you figure out how to break down the problem?
| you're going to have to review the output anyway.
| Iulioh wrote:
| It's useful to have the small functions all written.
|
| I program mostly in VBA these days (a little problematic as
| is a dead leanguage since 2006 and even then it was niche)
| and I have never recived a correct high level ""main"" sub
| but the AIs are pretty good at doing small subs I then
| organize.
|
| And yes, telling me where I make errors, they are pretty good
| at that
|
| At the end of the day I want reliability and there is no way
| I can't do what without full review.
|
| The funny thing is that they try to use the """best
| practices""" of coding where you would reasonably want to NOT
| have them.
| Frannky wrote:
| 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
| seg_lol wrote:
| This is slightly flawed. LLMs are search but the search space
| is sparse, the size of the question risks underspecification.
| The question controls the size of the encapsulated volume in
| that high dimensional space. The only advantage for small
| prompts is computational cost. In every other way they are a
| downside.
| bogtog wrote:
| 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
| listic wrote:
| Thanks for the advice! Could you please share how did you
| enable voice transcription for your setup and what it actually
| is?
| binocarlos wrote:
| I use https://github.com/braden-w/whispering with an OpenAI
| api key.
|
| I use a keyboard shortcut to start and stop recording and it
| will put the transcription into the clipboard so I can paste
| into any app.
|
| It's a huge productivity boost - OP is correct about not
| overthinking trying to be that coherent - the models are very
| good at knowing what you mean (Opus 4.5 with Claude Code in
| my case)
| listic wrote:
| I am all ready to believe that with LLMs it's not worth it
| trying to be too coherent: I _did_ successfully use LLMs to
| make sense of what incoherent-sounding people say. (in
| text)
| abdullahkhalids wrote:
| I just installed this app and it is very nice. The UX is
| very clean and whatever I say it transcribes it correctly.
| In fact I'm transcribing this comment with this app just
| now.
|
| I am using Whisper Medium. The only problem I see is that
| at the end of the message it sometimes puts a bye or a
| thank you which is kind of annoying.
| kapnap wrote:
| For me, on Mac, VoiceInk has been top notch. Got tired of
| superwhispr
| bogtog wrote:
| I'm using Wispr flow, but I've also tried Superwhisper. Both
| are fine. I have a convenient hotkey to start/end recording
| with one hand. Having it just need one hand is nice. I'm
| using this with the Claude Code vscode extension in Cursor.
| If you go down this route, the Claude Code instance should be
| moved into a separate window outside your main editor or else
| it'll flicker a lot
| lukax wrote:
| Spokenly on macOS with Soniox model.
| johnfn wrote:
| That's a fun idea. How do you get the transcript into Claude
| Code (or whatever you use)? What transcription service do you
| use?
| hn_throw2025 wrote:
| I'm not the person you're replying to, but I use Whispering
| connected to the whisper-large-v3-turbo model on Groq.
|
| It's incredibly cheap and works reliably for me.
|
| I have got it to paste my voice transcriptions into Chrome
| (Gemini, Claude, ChatGPT) as well as Cursor.
|
| https://github.com/EpicenterHQ/epicenter
| hurturue wrote:
| your OS might have a built in dictation thing. Google for
| that and try it before online services.
| bogtog wrote:
| There are a few apps nowadays for voice transcription. I've
| used Wispr Flow and Superwhisper, and both seem good. You can
| map some hotkey (e.g., ctrl + windows) to start recording,
| then when you press it again to stop, it'll get pasted into
| whatever text box you have open
|
| Superwhisper offers some AI post-processing of the text
| (e.g., making nice bullets or grammar), but this doesn't seem
| necessary and just makes things a bit slower
| quinncom wrote:
| I use Spokenly with local Parakeet 0.6B v3 model + Cerebras
| gpt-oss-120b for post-processing (cleaning up transcription
| errors and fixing technical mondegreens, e.g., `no JS` -
| `Node.js`). Almost imperceptible transcription and processing
| delay. Trigger transcription with right [?] key.
| ctoth wrote:
| According to Google this is the first time the phrase
| "technical mondegreens" was ever used. I really like it.
| rgbrgb wrote:
| I use Handy with Claude code. Nice to just have a key combo
| to transcribe into whatever has focus.
|
| https://github.com/cjpais/Handy
| elvin_d wrote:
| made this tool to press double control to start and another
| ctrl to stop which copies to the cliboard
|
| https://github.com/elv1n/para-speak/
| dominotw wrote:
| surprised ai companies are not making this workflow possible
| instead of leaving it upto users to figure out how to get voice
| text into prompt.
| alwillis wrote:
| > surprised ai companies are not making this workflow
| possible instead of leaving it upto users to figure out how
| to get voice text into prompt.
|
| Claude on macOS and iOS have native voice to text
| transcription. Haven't tried it but since you can access
| Claude Code from the apps now, I wonder if you use the Claude
| app's transcription for input into Claude Code.
| bogtog wrote:
| > Claude on macOS and iOS have native voice to text
| transcription
|
| Yeah, Claude/ChatGPT/Gemini all offer this, although
| Gemini's is basically unusable because it will immediately
| send the message if you stop talking for a few seconds
|
| I imagine you totally could use the app transcript and
| paste it in, but keeping the friction to an absolute
| minimum (e.g., just needing to press one hotkey) feels nice
| dyauspitr wrote:
| All the mobile apps make this very easy.
| Marsymars wrote:
| > 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.
|
| This doesn't feel relatable at all to me. If my writing speed
| is bottlenecked by thinking about what I'm writing, and my
| talking speed is significantly faster, that just means I've
| removed the bottleneck by _not thinking_ about what I 'm
| saying.
| hexaga wrote:
| Alternatively: some people are just better at / more
| comfortable thinking in auditory mode than visual mode & vice
| versa.
|
| In principle I don't see why they should have different
| amounts of thought. That'd be bounded by how much time it
| takes to produce the message, I think. Typing permits
| backtracking via editing, but speaking permits 'semantic
| backtracking' which isn't equivalent but definitely can do
| similar things. Language is powerful.
|
| And importantly, to backtrack in visual media I tend to need
| to re-saccade through the text with physical eye motions,
| whereas with audio my brain just has an internal buffer I
| know at the speed of thought.
|
| Typed messages might have higher _density_ of thought per
| token, though how valuable is that really, in LLM contexts?
| There are diminishing returns on how perfect you can get a
| prompt.
|
| Also, audio permits a higher bandwidth mode: one can scan and
| speak at the same time.
| dyauspitr wrote:
| I don't feel restricted by my typing speed, speaking is just
| so much easier and convenient. The vast majority of my
| ChatGPT usage is on my phone and that makes s2t a no brainer.
| bogtog wrote:
| That's fair. I sometimes find myself pausing or just talking
| in circles as I'm deciding what I want. I think when I'm
| speaking, I feel freer to use less precise/formal
| descriptions, but the model can still correctly interpret the
| technical meaning
|
| In either case, different strokes for different folks, and
| what ultimately matters is whether you get good results. I
| think the upside is high, so I broadly suggest people try it
| out
| j45 wrote:
| Speech also uses a different part of the brain, and maybe less
| finger coordination.
| Applejinx wrote:
| It's an AI. You might do better by phrasing it, 'Make a plan,
| and have questions'. There's nobody there, but if it's
| specifically directed to 'have questions' you might find they
| are good questions! Why are you asking, if you figure it'd be
| better to get questions? Just say to have questions, and it
| will.
|
| It's like a reasoning model. Don't ask, prompt 'and here is
| where you come up with apropos questions' and you shall have
| them, possibly even in a useful way.
| dboreham wrote:
| 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.
| morkalork wrote:
| 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.
| helterskelter wrote:
| 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.
| serial_dev wrote:
| 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.
| mmaunder wrote:
| Solid approach. Don't be shy about writing long prompts. We
| call that context engineering. The more you populate that
| context window with applicable knowledge and what exactly you
| want, the better the results. Also, having the model code and
| you talk to the model is helpful because it has the side effect
| of context engineering. In other words you're building up
| relevant context with that conversation history. And be acutely
| aware of how much context window you've used and how much is
| remaining and when a compaction will happen. Clear context as
| early as you can per run. Even if it's 90% remaining.
| coryvirok wrote:
| 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.
| firefax wrote:
| 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.
| fooker wrote:
| Think of some coding heavy project you always wanted to do but
| haven't had time for.
|
| Open up cursor-agent to make the repo scaffolding in an empty
| dir. (build system, test harness, etc. )
|
| Open up cursor or Claude code or whatever and just go nuts with
| it. Remember to follow software engineering best practices (one
| good change with tests per commit)
| graypegg wrote:
| I love the name "software carpentry" haha.
|
| IMO, I found those specific example tasks to be better handled
| by my IDE's refactoring features, though support for that is
| going to vary by project/language/IDE. I'm still more of a
| ludite when it comes to LLM based development tools, but the
| best case I've seen thus far is small first bites out of a big
| task. Working on an older no-tests code base recently, it's
| been things like setting up 4-5 tests that I'll expand on into
| a full test suite. You can't take more than a few "big" bites
| out of a task before you have 0 context as to what direction
| the vector soup sloshed in.
|
| So, in terms of carpentry, I don't want an LLM framer who's
| work I need to build off of, but an LLM millworker handing me
| the lumber is pretty useful.
| mmusc wrote:
| Funny usually a lot of my code is software plumbing, and
| gardening.
|
| In terms of ai assisted programming. I microanage my ai. Give
| it specific instructions with single steps. Don't really let
| it build ehoe files by itself as it usually makes a mess of
| things, bit it's useful when doing predictable changes and
| marginally faster than doing it manually.
| graypegg wrote:
| Yeah I can totally see that working well! I think the main
| thing is taking small, specific steps that keep you in the
| loop, and less so about the actual act of typing the
| specific bytes that are fed into the compiler, though I
| guess I still find that more efficient for myself than
| trying to describe what I want ~90% of the time.
| esafak wrote:
| Practice on an open source repo to allay your privacy fears.
| owlninja wrote:
| 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.
| hurturue wrote:
| 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
| thinkingtoilet wrote:
| 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.
| seg_lol wrote:
| 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.
| ipunchghosts wrote:
| 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.
| daxfohl wrote:
| Though remember that it's not a human. It's easy to waste a lot
| of time convincing it to do something in a certain way, then
| one prompt later it forgets everything you said and reverts
| back to its previous behavior. (Yes humans can do that too, but
| not usually to this level).
|
| It's important (though often surprisingly hard!) to remember
| it's just a tool, so if it's not doing things the way you want,
| start over with something else. Don't spend too much time on a
| lost cause.
| bcherny wrote:
| 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!
| dotancohen wrote:
| > I add to my team's CLAUDE.md multiple times a week.
|
| How big is that file now? How big is too big?
| bcherny wrote:
| Try to keep it under 1k tokens or so. We will show you a
| warning if it might be too big.
|
| Ours is maybe half that size. We remove from it with every
| model release since smarter models need less hand-holding.
|
| You can also break up your CLAUDE.md into smaller files, link
| CLAUDE.mds, or lazy load them only when Claude works in
| nested dirs.
|
| https://code.claude.com/docs/en/memory
| tomviner wrote:
| How do you know what to remove?
| blobbers wrote:
| 1k tokens, google says thats about 750 words. That's
| actually pretty short, any chance you could post a few
| samples of instructions or even link to a publicly
| available file CLAUDE.md you recommend?
| dotancohen wrote:
| That is seriously short. I've asked Claude Code to add
| instructions to CLAUDE.md and my one line request has
| resulted in tens of lines added to the file.
| hanska wrote:
| yes if you tell llm to do things it will be too verbose.
| either explicitly instruct the length ("add 5 lines
| bulletpoints, tldr format") or just write it yourself.
| bgilly wrote:
| I've been fine tuning mine pretty often. Do you have any
| Claude.md files you can share as good examples? Especially
| with opus 4.5.
|
| And thank you for your work!! I focus all of my energy on
| helping families stay safe online, I make educational
| content and educational products (including software).
| Claude Code has helped me amplify my efforts and I'm able
| to help many more families and children as a result. The
| downstream effects of your work on Claude Code are awesome!
| I've been in IT since 1995 and your tools are the most
| powerful tools I've ever used, by far.
| kxrm wrote:
| Something to keep in mind is if your CLAUDE.md file is
| getting large, consider alternative approaches especially for
| repeatable tasks. Using slash commands and skills for
| workflows that are repeatable is a really nice way to keep
| your rules file from exploding. I have slash commands for
| code review, and git commit management. I have skills for
| complex tool interactions. Our company has it's own
| deployment CLI tool so using skills to make Claude Code an
| expert at using this tool has done wonders to improve Claude
| Codes performance when working on CI/CD problems.
|
| I am currently working on a new slash command /investigate
| <service> that runs triage for an active or past incident.
| I've had Claude write tools to interact with all of our
| partner services (AWS, JIRA, CI/CD pipelines, GitLab,
| Datadog) and now when an incident occurs it can quickly put
| together an early analysis of a incident finding the right
| people to involve (not just owners but people who last
| touched the service), potential root causes including service
| dependency investigations.
|
| I am putting this through it's paces now but early results
| are VERY good!
| goalieca wrote:
| > I add to my team's CLAUDE.md multiple times a week.
|
| This concerns me because fighting tooling is not a positive
| thing. It's very negative and indicates how immature everything
| is.
| bcherny wrote:
| You might be misunderstanding what a CLAUDE.md is. It's not
| about fighting the model, rather it's giving the model a
| shortcut to get the context it needs to do its work. You
| don't have to have one. Ours is 100% written by Claude
| itself.
| seunosewa wrote:
| That's not the same thing as adding rules by yourself based
| on your experiences with Claude.
| jedberg wrote:
| The Claude MD is like the documentation you hand to a new
| engineer on your team that explains details about your code
| that they wouldn't otherwise know. It's not bad to need one.
| thfuran wrote:
| But that documentation shouldn't need to be updated nearly
| every other day.
| jm4 wrote:
| It does if it's incomplete or otherwise doesn't
| accurately convey what people need to know.
| kxrm wrote:
| If you are consistent with how you do your projects you
| shouldn't need to update CLAUDE.md nearly every day.
| Early on, I was adjusting it nearly every day for maybe a
| couple of projects but now I have very little need to
| make any adjustments.
|
| Often the challenge is users aren't interacting with
| Claude Code about their rules file. If Claude Code
| doesn't seem to be working with you ask it why it ignore
| a rule. Often times it provides very useful feedback to
| adjust the rules and no longer violate them.
|
| Another piece of advice I can give is to clear your
| context window often! Early in my start in this I was
| letting the context window auto compact but this is bad!
| Your model is it's freshest and "smartest" when it has a
| fresh context window.
| nrds wrote:
| It takes a lot of uncached tokens to let it learn about
| your project again.
| Bjartr wrote:
| Consider that every time you start a session with Claude
| Code. It's effectively a new engineer. The system doesn't
| learn like a real person does, so for it to improve over
| time you need to manually record the insights that for a
| normal human would be integrated by the natural learning
| process.
| newsoftheday wrote:
| Reminds me of that Nicole Kidman movie Before I Go to
| Sleep.
| handfuloflight wrote:
| Sleep time compute architectures are changing this.
| Marsymars wrote:
| I certainly _could_ be updating the documentation for new
| devs very frequently - the problem with devs is that they
| don 't bother reading the documentation.
| Gud wrote:
| Why not?
| bitwize wrote:
| Have you never looked at your work's Confluence? Worse,
| have you never spent time at a company where the
| documentation _wasn 't_ frequently updated?
| kidbomb wrote:
| Does the same happens if I create an AGENTS.md instead?
| red2awn wrote:
| Claude Code does not support AGENTS.md, you can symlink it to
| CLAUDE.md to workaround it. Anthropic: pls support!
| kevinherron wrote:
| Use AGENTS.md for everything, then put a single line in
| CLAUDE.md: @AGENTS.md
| handfuloflight wrote:
| Get a grep!
| cafebeen wrote:
| Thanks for your work great work on Claude Code!
|
| One other feature with CLAUDE.md I've found useful is imports:
| prepending @ to a file name will force it to be imported into
| context. Otherwise, whether a file is read and loaded to
| context is dependent on tool use and planning by the agent
| (even with explicit instructions like "read file.txt"). Of
| course this means you have to be judicial with imports.
| moribvndvs wrote:
| Do you recommend having Claude dump your final plan into a
| document and having it execute from that piece by piece?
|
| I feel like when I do plan mode (for CC and competing
| products), it seems good, but when I tell it to execute the
| output is not what we planned. I feel like I get slightly
| better results executing from a document in chunks (which of
| course necessitates building the iterative chunks into the
| plan).
| justatdotin wrote:
| a very common pattern is planner / executor.
|
| yes the executor only needs the next piece of the plan.
|
| I tend to plan in an entirely different environment, which
| fits my workflow and has the added benefit of providing a
| clear boundary between the roles. I aim to spend far more
| time planning than executing. if I notice getting more caught
| up in execution than I expected, that's a signal to revise
| the plan.
| danenania wrote:
| I often use multiple documents to plan things that are too
| large to fit into a single planning mode session. It works
| great.
|
| You can also use it in conjunction with planning mode--use
| the documents to pin everything down at a high-to-medium
| level, then break off chunks and pass those into planning
| mode for fine-grained code-level planning and a final
| checking over before implementation.
| nrds wrote:
| > Use Opus 4.5.
|
| This drives up price faster than quality though. Also increases
| latency.
| bakugo wrote:
| Obviously the Anthropic employee advertising their product
| wants you to pay as much as possible for it.
| handfuloflight wrote:
| The generosity of the Max plans indicates otherwise.
| sothatsit wrote:
| Opus 4.5 is significantly better if you can afford it.
|
| They also recently lowered the price for Opus 4.5, so it is
| only 1.67x the price of Sonnet, instead of 5x for Opus 4.
| minimaxir wrote:
| There's a counterintuitive pricing aspect of Opus-sized LLMs
| in that they're so much smarter that in some cases, it can
| solve the problem faster and with much fewer tokens that it
| can end up being cheaper.
| matt3210 wrote:
| I've yet to see any real work get done with agents. Can you
| share examples or videos of real production level work getting
| done? Maybe in a tutorial format?
|
| My current understanding is that it's for demos and toy
| projects
| danenania wrote:
| I know of many experienced and capable engineers working on
| complex stuff who are driving basically all their development
| through agents. This includes production level work. This is
| the norm now in the SV startup world at least.
|
| You don't just YOLO it. You do extensive planning when
| features are complex, and you review output carefully.
|
| The thing is, if the agent isn't getting it to the point
| where you feel like you might need to drop down and edit
| manually, agents are now good enough to do those same "manual
| edits" with nearly 100% reliability if you are specific
| enough about what you want to do. Instead of "build me x, y,
| z", you can tell it to rename variables, restructure
| functions, write specific tests, move files around, and so
| on.
|
| So the question isn't so much whether to use an agent or edit
| code manually--it's what level of detail you work at with the
| agent. There are still times where it's easier to do things
| manually, but you never really _need_ to.
| matt3210 wrote:
| Can you show some example? I feel like there would be
| streams or YouTube lets plays on this if it was working
| well
| danenania wrote:
| A lot of that would be people working on proprietary code
| I guess. And most of the people I know who are doing this
| are building stuff, not streaming or making videos. But
| I'm sure there must be content out there--none of this is
| a secret. There are probably engineers working on open
| source stuff with these techniques who are sharing it
| somewhere.
| matt3210 wrote:
| That's understandable, I also wouldn't stream my next
| idea for everyone to see
| dmurvihill wrote:
| Let's see it then
| sixtyj wrote:
| I would like to see it as well. It seems to me that
| everybody sells shovels only. But nobody haven't seen
| gold yet. :)
| shsush wrote:
| The real secret to agent productivity is letting go of
| your understanding of the code and trusting the AI to
| generate the proper thing. Very pro agent devs like
| ghuntley will all say this.
|
| And it makes sense. For most coding problems the
| challenge isn't writing code. Once you know what to write
| typing the code is a drop in the bucket. AI is still very
| useful, but if you really wanna go fast you have to give
| up on your understanding. I've yet to see this work well
| outside of blog posts, tweets, board room discussions
| etc.
| hansmayer wrote:
| Not to blow your bubble, but I've seen agents expose
| Stripe credentials by hardcoding them as text into a
| react frontend app, so, no kids, do not "let go" of code
| understanding, lest you want to appear as the next story
| along the lines of "AI dropped my production database".
| urig wrote:
| That's just irresponsible advice. There is so little
| actual evidence of this technology being able to produce
| high quality maintainable code that asking us to trust it
| blindly is borderline snake-oil peddling.
| hansmayer wrote:
| Not borderline - it is just straight snake-oil peddling.
| Kubuxu wrote:
| I don't see how I would feel comfortable pushing the
| current output of LLMs into high-stakes production (think
| SLAs, SRE).
|
| Understanding of the code in these situation is more
| important than the code/feature existing.
| danenania wrote:
| You can use an agent while still understanding the code
| it generates in detail. In high stakes areas, I go
| through it line by line and symbol by symbol. And I
| rarely accept the first attempt. It's not very different
| from continually refining your own code until it meets
| the bar for robustness.
|
| Agents make mistakes which need to be corrected, but they
| also point out edge cases you haven't thought of.
| shsush wrote:
| I agree and am the same. Using them to enhance my
| knowledge and as well as autocomplete on steroids is the
| sweet spot. Much easier to review code if im "writing" it
| line by line.
|
| I think the reality is a lot of code out there doesn't
| need to be good, so many people benefit from agents etc.
| submain wrote:
| > The real secret to agent productivity is letting go of
| your understanding of the code and trusting the AI to
| generate the proper thing
|
| The few times I've done that, the agent eventually faced
| a problem/bug it couldn't solve and I had to go and read
| the entire codebase myself.
|
| Then, found several subtle bugs (like writing private
| keys to disk even when that was an explicit instruction
| not to). Eventually ended up refactoring most of it.
|
| It does have value on coming up with boilerplate code
| that I then tweak.
| hansmayer wrote:
| +1 here. Lets see those productivity gains!
| PaulHoule wrote:
| I use Junie to get tasks done all the time. For instance I
| had two navigation bars in an application which had different
| styling and I told it make the second one look like the first
| and... it made a really nice patch. Also if I don't
| understand how to use some open source dependency I check the
| project out and ask Junie questions about it like "How do I
| do X?" or "How does setting prop Y have the effect of Z?" and
| frequently I get the right answer right away. Sometimes I
| describe a bug in my code and ask if it can figure it out and
| often it does, ask for a fix and often get great results.
|
| I have a React application where the testing situation is
| FUBAR, we are stuck on an old version of React where tests
| like enzyme that really run react are unworkable because the
| test framework can never know that React is done rendering --
| working with Junie I developed a style of true unit tests for
| class components (still got 'em) that tests tricky methods in
| isolation. I have a test file which is well documented
| explaining the situation around tests and ask "Can we make
| some tests for A like the tests in B.test.js, how would you
| do that?" and if I like the plan I say "make it so!" and it
| does... frankly I would not be writing tests if I didn't have
| that help. It would also be possible to mock useState() and
| company and might do that someday... It doesn't bother me so
| much that the tests are too tightly coupled because I can
| tell Junie to fix or replace the tests if I run into trouble.
|
| For me the key things are: (1) understanding from a project
| management perspective how to cut out little tasks and
| questions, (2) understanding enough coding to know if it is
| on the right track (my non-technical boss has tried vibe
| coding and gets nowhere), (3) accepting that it works
| sometimes and sometimes it doesn't, and (4) recognizing
| context poisoning -- sometimes you ask it to do something and
| it gets it 95% right and you can tell it to fix the last bit
| and it is golden, other times it argues or goes in circles or
| introduces bugs faster than it fixes them and as quickly as
| you can you recognize that is going on and start a new
| session and mix up your approach.
| matt3210 wrote:
| This is a lot of good reasons not to use it yet IMO
| matt3210 wrote:
| Manually styling two similar things the same way is a code
| smell. Ask the ai to make common components and use them
| for both instead of brute forcing them to look similar.
| PaulHoule wrote:
| Yeah, I thought about this in that case. I tend to think
| the way you do to the extent that it is sometimes a
| source of conflict with other people I work with.
|
| These navbars are similar but not the same, both have a
| pager but they have other things, like one has some drop
| downs and the other has a text input. Styled "the same"
| means the line around the search box looks the same as
| the lines around the numbers in the pager, and Junie got
| that immediately.
|
| In the end the patch touched css classes in three lines
| of one file and added a css rule -- it had the caveat
| that one of the css classes involved will probably go
| away when the board finally agrees to make a visual
| change we've been talking about for most of a year but I
| left a comment in the first navbar warning about that.
|
| There are plenty of times I ask Junie to try to
| consolidate multiple components or classes into one and
| it does that too as directed.
| commanderkeen08 wrote:
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/... That's what slots are for
| MontyCarloHall wrote:
| Good question. Why hasn't there been a profusion of new game-
| changing software, fixes to long-standing issues in open-
| source software, any nontrivial shipped product at all? Heck,
| why isn't there a cornucopia of new apps, even trivial ones?
| Where is all the shovelware [0]? Previous HN discussion here
| [1].
|
| Don't get me wrong, AI is at least as game-changing for
| programming as StackOverflow and Google were back in the day.
| I use it every day, and it's saved me hours of work for
| certain specific tasks [2]. But it's simply not a massive 10x
| force multiplier that some might lead you to believe.
|
| I'll start believing when maintainers of complex, actively
| developed, and widely used open-source projects (e.g. ffmpeg,
| curl, openssh, sqlite) start raving about a massive uptick in
| positive contributions, pointing to a concrete influx of
| high-quality AI-assisted commits.
|
| [0] https://mikelovesrobots.substack.com/p/wheres-the-
| shovelware...
|
| [1] https://news.ycombinator.com/item?id=45120517
|
| [2] https://news.ycombinator.com/item?id=45511128
| hansmayer wrote:
| Well, the LLM industry is not completely without results.
| We do have ever increasing frequency of outages in major
| Internet services...Somehow correlates with the AI mandates
| major tech corps seem to pushing now internally.
| spreiti wrote:
| I use GitHub Copilot in Intellij with Claude Sonnet and the
| plan mode to implement complete features without me having to
| code anything.
|
| I see it as a competent software developer but one that
| doesn't know the code base.
|
| I will break down the tasks to the same size as if I was
| implementing it. But instead of doing it myself, I roughly
| describe the task on a technical level (and add relevant
| classes to the context) and it will ask me clarifying
| questions. After 2-3 rounds the plan usually looks good and I
| let it implement the task.
|
| This method works exceptionally well and usually I don't have
| to change anything.
|
| For me this method allows me to focus on the architecture and
| overall structure and delegate the plumbing to Copilot.
|
| It is usually faster than if I had to implement it and the
| code is of good quality.
|
| The game changer for me was plan mode. Before it, with agent
| mode it was hit or miss because it forced me to one shot the
| prompt or get inaccurate results.
| hansmayer wrote:
| Yeah, but what did you produce with it in the end? Show us
| the end result please.
| spreiti wrote:
| I cannot show it because the code belongs to my employer.
| hansmayer wrote:
| Ah yes of course. But no one asked for the code really.
| Just show us the app. Or is it some kinda super-duper
| secret military stuff you are not even supposed to
| discuss, let alone show.
| williamcotton wrote:
| I've been writing an experimental pipeline-based web app
| DSL with Claude Code for that last little while in my
| spare time. Sort of bash-like with middleware for lua,
| jq, graphql, handlebars, postgres, etc.
|
| Here's an already out of date and unfinished blog post
| about it: https://williamcotton.com/articles/introducing-
| web-pipe
|
| Here's a simple todo app: https://github.com/williamcotto
| n/webpipe/blob/webpipe-2.0/to...
|
| Check out the BDD tests in there, I'm quite proud of the
| grammar.
|
| Here's my blog: https://github.com/williamcotton/williamc
| otton.com/blob/mast...
|
| It's got an LSP as well with various validators, jump to
| definitions, code lens and of course syntax highlighting.
|
| I've yet to take screenshots, make animated GIFs of the
| LSP in action or update the docs, sorry about that!
|
| A good portion of the code has racked up some tech debt,
| but hey, it's an experiment. I just wanted to write my
| own DSL for my own blog.
| dmd wrote:
| I would LOVE to use Opus 4.5, but it means I (a merely Pro
| peon) can work for maybe 30 minutes a day, instead of 60-90.
| epolanski wrote:
| > 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.
|
| Sure, for 4/5 interactions then will ignore those completely :)
|
| Try for yourself: add to CLAUDE.md an instruction to always
| refer to you as Mr. bcherny and it will stop very soon.
| Coincidentally at that point also loses tracks of all the other
| instructions.
| dayjah wrote:
| The Attention algo does that, it has a recency bias. Your
| observation is not necessarily indicative of Claude not
| loading CLAUDE.md.
|
| I think you may be observing context rot? How many back and
| forths are you into when you notice this?
| Fargren wrote:
| That explains why it happens, but doesn't really help with
| the problem. The expectation I have as a pretty naive user,
| is that what is in the .md file should be permanently in
| the context. It's good to understand why this is not the
| case, but it's unintuitive and can lead to frustration.
| It's bad UX, if you ask me.
|
| I'm sure there are workarounds such as resetting the
| context, but the point is that god UX would mean such
| tricks are not needed.
| girvo wrote:
| Yeah the current best approach to aggressively compact
| and recreate context by starting fresh. It's awkward and
| I wish I didn't have to.
| epolanski wrote:
| I know the reason, I just took the opportunity of answering
| to a claude dev to point out why it's no panacea and how
| this requires consistent context management.
|
| Real semi-productive workflow is really a "write plans in
| markdowns -> new chat -> implement few things -> update
| plans -> new chat, etc".
| SV_BubbleTime wrote:
| The number of times I've written "read your own fucking
| Claude.md file" is a bit too numerous.
|
| _"You're absolutely right! I see here you don't want me to
| break every coding convention you have specified for me!"_
| bcherny wrote:
| Yeah, adherence is a hard problem. It should be feeling much
| better in newer models, especially Opus 4.5. I generally find
| that Opus listens to me the first time.
| matt3210 wrote:
| Does all my code get uploaded to the service?
| Etheryte wrote:
| Hah, that's funny. Claude can't help but mess all the comments
| in the code up even if I explicitly tell it to not change any
| comments five times. That's literally the experience I had
| before opening this thread, never mind how often it completely
| ignores CLAUDE.md.
| tlarkworthy wrote:
| also after you have a to-and-fro to course correct it on a
| task, run this self-reflection prompt
|
| https://gist.github.com/a-c-m/f4cead5ca125d2eaad073dfd71efbc...
|
| That will moves stuff that required manually clarifying back
| into the claude.md (or a useful subset you pick). It does a
| much better job of authoring claude.md than I do.
| hansmayer wrote:
| Hey Boris from the Claude Code team - could you guys please be
| so kind so as to stop pushing that narrative about CLAUDE.md,
| either yourselves or through influencers and GenAI-grifters?
| The reason being, it is simply not true. A lot of the time the
| instructions will be ignored. Actually, the term "ignored" is
| putting the bar too high, because your tool does not
| intentionally "ignore", not having sentience and knowledge. We
| experience the effects of the instructions being ignored,
| because your software is not deterministic, its merely guessing
| the next token, and sometimes those instructions tacked onto
| the rest of the context statistically do not match what we as
| humans expect to see (while its perfectly logical for your
| machine learning text generator, based on the datasets it was
| trained on).
| blitz_skull wrote:
| This seems pretty aggressive considering this is all just
| personal anecdote.
|
| I update my CLAUDE.md all the time and notice the effects.
|
| Why all the snark?
| hansmayer wrote:
| Is it really just a personal anecdote ? Please do read some
| other comments on this post. The snark comes from everyone
| and their mother recommending "just write CLAUDE.md", when
| it is clear that this technology does not have intrinsic
| capability to perform reliable outputs based on human
| language input.
| blitz_skull wrote:
| Yeah... that's the point of LLMs: variable output. If
| you're using them for 100% consistent output, you're
| using the wrong tool.
| hansmayer wrote:
| Is it? So you are saying software should not be
| consistent? Or that LLMs should not be used for software
| development, aside from toy-projects?
| simonw wrote:
| CLAUDE.md is read on session startup.
|
| If you're continually finding that it's being forgotten,
| maybe you're not starting fresh sessions often enough.
| jMyles wrote:
| 3. Puppeteer? Or Playwright? I haven't been able to make
| Puppeteer work for the past 8 weeks or so ("failed to
| reconnect"). Do you have a doc on this?
| glamp wrote:
| Hey Boris,
|
| I couldn't agree more. And using Plan mode was a major
| breakthrough for me. Speaking of Plan Mode...
|
| I was previously using it repeatedly in sessions (and was
| getting great results). The most recent major release
| introduced this bug where it keeps referring back to the first
| plan you made in a session even when you're planning something
| else (https://github.com/anthropics/claude-code/issues/12505).
|
| I find this bug incredibly confusing. Am I using Plan Mode in a
| really strange way? Because for me this is a showstopper bug-my
| core workflow is broken. I assume I'm using Claude Code
| abnormally otherwise this bug would be a bigger issue.
| halfcat wrote:
| > _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.
| UncleEntity wrote:
| > But generally people let their agent make whatever change it
| makes and then wonder why trains are flying off the tracks.
|
| IMO, this is the biggest issue. Well, along with just straight
| up ignoring what you tell it and doing whatever it thinks
| should be done.
|
| But, to answer the actual thread question: Make it work (all
| the tests pass) then make it right is the way I'm getting
| quality work out of the robots. As long as you watch them to
| make sure they don't either change the tests to pass on buggy
| code or change the code to pass on buggy tests (yes, Claude is
| quite proficient and eager to do both) then the code gets
| better and better as new stuff is added and the 'flow of
| computation' is worked out.
|
| Oh, and have an actual plan to follow so they don't get
| distracted at the first issue and say they're finished because
| they fixed some random unrelated bug. I've also found it
| helpful to have them draft up such a plan while they're knee
| deep in that section of the code for related work so they don't
| have to figure it all out again from scratch and try to add a
| few extra levels of abstraction just because.
| nisalperi wrote:
| I wrote about my experience from the last year. Hope you find
| this helpful
|
| https://open.substack.com/pub/sleuthdiaries/p/guide-to-effec...
| dominotw wrote:
| dont forget to include "pls don't make mistakes"
| cat_plus_plus wrote:
| 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.
| noiv wrote:
| 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.
| caseyw wrote:
| 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.
| daxfohl wrote:
| 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.
| ebcode wrote:
| > A 10% improvement every month gets to be a 10x improvement in
| (math...)
|
| 1.1^24=9.85, so yeah, if you could reliably get a 10% speed-up
| each month, you'd get to 10x in roughly 2 years. (But I'd
| expect the speed-up per month to be non-linear.)
| orwin wrote:
| 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.
| Fire-Dragon-DoL wrote:
| 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 .
| red2awn wrote:
| Opus 4.5 is the highest quality code I've seen out of LLMs,
| still some way to go to match programmers who care, but much
| better than most people. I find it enough to let it write the
| code and then manually polish it afterwards.
| christophilus wrote:
| Same. It is finally almost always more productive for me to
| use vs doing it myself. What this means for my career and
| life, I don't know. But, I do think the job for most of us is
| going to look very different moving forward.
| mongrelion wrote:
| My experience with generating code with AI is very limited
| across a limited set of programming languages but whenever it
| has produced low quality code, it has been able to better
| itself with further instructions. Like "oh no, that is not the
| right naming convention. Please use instead" or "the choice of
| design pattern here is not great because ${reasons}. Produce 2
| alternative solutions using x or y" and in nearly every case it
| produces satisfactory results.
|
| Has this also been your experience?
| vaibhavgeek wrote:
| 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.
| michelsedgh wrote:
| 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.
| justatdotin wrote:
| 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.
| JackSlateur wrote:
| 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;
| ransom1538 wrote:
| This is the fastest way to unemployment benefits (if that is
| the goal).
| eqvinox wrote:
| This is just meaningless knee-jerking, try making an actual
| argument. At least the GP is arguing that more use of AI
| leads to loss of personal coding skills. It's unclear at this
| point what level AI will grow to, i.e. it could hit a hard
| wall at 70% of a good programmer's ability, and in that case
| you would really want those personal coding skills since
| they'll be worth a lot. It could also far exceed a good
| programmer, in which case the logic reverses and you want
| those AI handling skills...
|
| NB: I'm talking about skill cap here, not speed of execution.
| Of course, an AI will be faster than a programmer... _*if*_
| it can handle the job, and _*if*_ you can trust it enough to
| not need even more time in review...
| __mharrison__ wrote:
| 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)
| Galorious wrote:
| 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.
| bulletsvshumans wrote:
| 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
| cardanome wrote:
| 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,
| swatcoder wrote:
| > 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.
| sdn90 wrote:
| 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.
| benzguo wrote:
| 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
| johnsmith1840 wrote:
| 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.
| j45 wrote:
| Follow and learn from peopel on youtube who formerly had the same
| skill level as you did now.
| nmaley wrote:
| 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.
| daxfohl wrote:
| 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.
| siscia wrote:
| 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.
| dboon wrote:
| 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.
| AndrewKemendo wrote:
| 100% concur with this as owner of multiple 20k+ LOC repos with
| between 10-30% unmodified AI code in production
|
| If you treat it like a rubber duck it's magic
|
| If you think the rubber duck is going to think for you then you
| shouldn't even start with them.
| handfuloflight wrote:
| This is a great drill down.
| shsush wrote:
| > it should be as concise as possible
|
| What's more concise than code? From my experience, by the time
| I've gotten an English with code description accurate enough
| for an agent I could have done it myself. Typing isn't a hard
| part.
|
| LLMs/agents have many other uses, but if you're not offloading
| your thinking you're not really going any faster wrt letting
| them write code via a prompt.
| jdelsman wrote:
| 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.
| rokoss21 wrote:
| 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.
| twodave wrote:
| 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.
| rr808 wrote:
| 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.
| xpe wrote:
| When the world is complicated, entangled, and rapidly changing,
| would you _expect_ there to be one centralized official guide?*
|
| At the risk of sounding glib or paternalistic -- but I'm going
| to say it anyway, because once you "see it" it won't feel like
| a foreign idea being imposed on you -- there are ways that help
| to lower and even drop expectations.
|
| How? To mention just one: good reading. Read "Be a new
| homunculus" [1]. To summarize, visualize yourself like you are
| the "thing that lives in your brain". Yes, this is non-sense
| but try it anyway.
|
| If you find various ways to accept "the world is changing
| faster than ever before" _and_ it feels like too much. Maybe
| you are pissed off or anxious about AI. Maybe AI is being
| "heavily encouraged" for you (on you?) at work. Maybe you feel
| like we're living in an unsustainable state of affairs -- don't
| deny it. Dig into that feeling, talk about it. See where it
| leads you. Burying these things isn't a viable long-term
| strategy.**
|
| * There is an "awesome-*" GitHub repository for collecting
| recommended resources to help with Claude Code: [2] But still
| requires a lot of curation and end-user experimentation: [2]
| There are few easy answers in a dynamic uncertain world.
|
| ** Yes I'm intentionally cracking the door open to "Job loss is
| scary. It is time to get real on this, including political
| activism."
|
| [1]: https://mindingourway.com/be-a-new-homunculus/
|
| [2]: https://github.com/hesreallyhim/awesome-claude-code
| rr808 wrote:
| Thanks yes of course you're right, still frustrating. I'm
| nearing retirement so not really worried about job loss, just
| want to make use of the tools.
| asgraham wrote:
| 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)
| bgwalter wrote:
| 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).
| bikeshaving wrote:
| 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.
| whatever1 wrote:
| 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.
| robertpiosik wrote:
| Try a free and open-source VS Code plugin "Code Web Chat".
| nextaccountic wrote:
| 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
| theahura wrote:
| 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. We have
| ~100 users right now in a small focus group and have extremely
| high retention, with a lot of folks saying that these configs
| completely changed their relationship with coding agents.
|
| It's a one-shot install. 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)
___________________________________________________________________
(page generated 2025-12-13 23:00 UTC)