Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agentic Coding Recommendations

lucumr.pocoo.org

Post reply on HN
Print view View original

71–80 of 210 posts

Re: Agentic Coding Recommendations

#71

Post by phito »

bananapub wrote: post #61
phito wrote: post #41

Earlier quoted context omitted.

I will definitely sleep on agents. Normal LLM use, fine, but I am not giving up reasoning.

this is kind of a weird position to take. you're the captain, you're the person reviewing the code the LLM (agent or not) generates, you're the one asking for the code you want, you're in charge of deciding how much effort to put in to things, and especially which things are most worth your effort . all this agent stuff sounded stupid to me until I tried it out in the last few weeks, and personally, it's been great -…

If I have to review all code code it's writing, I'd rather write it myself (maybe with the help of an LLM).

> anyway, obviously do whatever you want, but deriding something you've not looked in to isn't a hugely thoughtful process for adapting to a changing world.

I have tried it. Not sure I want to be part of such world, unfortunately.

> the experience is pretty much like being a senior dev with a bunch of very eager juniors who read very fast.

I... don't want that. Juniors just slow me down because I have to check what they did and fix their mistakes.

(this is in the context of professional software development, not making scripts, tinkering etc)

Re: Agentic Coding Recommendations

#72

Post by rolisz »

chuckadams wrote: post #46
yuri91 wrote: post #16

So using agents forces (or at least nudges) you to use go and tailwind, because they are simple enough (and abundant in the training data) for the AI to use correctly. Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge? Competing with the existing alternatives will be too hard. You won't even be able to ask real humans for help on platf…

> So using agents forces (or at least nudges) you to use go and tailwind Not even close, and the article betrays the author's biases more than anything else. The fact that their Claude Code (with Sonnet) setup has issues with the `cargo test` cli for instance is hardly a categorical issue with AIs or cargo, let alone rust in general. Junie can't seem to use its built-in test runner tool on PHP tests either, that does…

I tried Junie in PyCharm and it had big problems with running tests or even using the virtual environment set up in PyCharm for that project.

You'd expect more from the company that is developing both the IDE and the AI agent...

Re: Agentic Coding Recommendations

#73

Post by rolisz »

andyferris wrote: post #59
bananapub wrote: post #51

Earlier quoted context omitted.

it shouldn't be expensive - you can pay for Pro ($20/month) or Max ($100 or $200/month) to get what would cost >> $1000/month in API costs.

Can you use Claude Code with Pro? I was trying to figure this out and I thought you couldn't (unless you enter an API key and pay for tokens).

Yes, since last week or so.

Re: Agentic Coding Recommendations

#74

Post by owebmaster »

diggan wrote: post #56
cpursley wrote: post #54

Earlier quoted context omitted.

How are you getting results when Ruby has no type system? That seems like where half the value of LLM coding agents are (dumping in type errors and it solving them).

Bunch of unit, functional and E2E tests, just like before LLMs :) Haven't tried with Ruby specifically but works well with JavaScript and other dynamic languages so should work fine with Ruby too.

I wonder if people that loves typescript never wrote tests and that is why they are so fascinated with types for dynamic languages. I guess they have never been really productive.

Re: Agentic Coding Recommendations

#75

Post by Keats »

energy123 wrote: post #39
exfalso wrote: post #35

Earlier quoted context omitted.

Exact same experience. I have no clue what other people are doing. I was hunting for use cases where it could be used and it kept not working. I don't get it.

Is it only Rust that you've had this experience with or is it a general thing?

I'm not sure if it's Rust related. It manages to write the Rust code just fine, it's just that it doesn't seem to

- think of everything that is needed for a feature (fixable via planning at the beginning)

- actually follow that plan correctly

I just tried with a slightly big refactor to see if some changes would improve performance. I had it write the full plan and baseline benchmarks to disk, then let it go in yolo mode. When it was done it only implemented something like half of the planning phases and was saying the results look good despite all the benchmarks having regressed.

Re: Agentic Coding Recommendations

#76

Post by gk1 »

Nice to see container use mentioned (https://github.com/dagger/container-use). I work with the team that made it (a lot of ex-Docker folks including the creator of Docker.)

Running agents in parallel will be a big deal as soon as we learn (or the agents learn) how to reliably work with just one.

Even before then, if you're trying to get work done while the agent is doing its own thing or you find yourself watching over the agent's "shoulder" out of fear it'll change something you didn't ask it to change, then it's useful to run it in a containerized dev environment.

Container use is definitely early but moving quickly, and probably improved even since this post was published. We're currently focused on stability, reducing git confusion, better humanagent interaction, and environment control.

Re: Agentic Coding Recommendations

#77

Post by gk1 »

benob wrote: post #2

> This is not an advertisment for Claude Code. It's just the agent I use at the moment. What else is there? Alternatives that are similar in their user experiences are OpenCode, goose, Codex and many others. There is also Devin and Cursor's background agents but they work a bit different in that they run in the cloud. What do you recommand to get a Claude-code-like experience in the open-source + local llm ecosystem?

I see a new alternative (or attempt at one) come out every few days, so it shouldn't be long before we have "the one" alternative.

https://www.app.build/ was just launched by the Neon -- err, Databricks -- team and looks promising.

Re: Agentic Coding Recommendations

#78

Post by GardenLetter27 »

darkxanthos wrote: post #48

I stumbled into Agentic Coding in VS Code Nightlys with co-pilot using Claude Sonnet 4 and I've been silly productive. Even when half my day is meetings, you wouldn't be able to tell from my git history. My thinking now is removed from the gory details and is a step or two up. How can I validate the changes are working? Can I understand this code? How should it be structured so I can better understand it? Is there mo…

I trust it more with Rust than Python tbh, because with Python you need to make sure it runs every code path as the static analysis isn't as good as clippy + rust-analyzer.

Re: Agentic Coding Recommendations

#79

Post by bitwize »

Keats wrote: post #75
energy123 wrote: post #39

Earlier quoted context omitted.

Is it only Rust that you've had this experience with or is it a general thing?

I'm not sure if it's Rust related. It manages to write the Rust code just fine, it's just that it doesn't seem to - think of everything that is needed for a feature (fixable via planning at the beginning) - actually follow that plan correctly I just tried with a slightly big refactor to see if some changes would improve performance. I had it write the full plan and baseline benchmarks to disk, then let it go in yolo…

I've encountered human Rust programmers that exhibit this behavior. I think that Rust may be falling victim to its own propaganda, as developers come to believe that the borrow checker will fix their logic errors, not just flag up memory management that's at risk of buffer overflow or UAF.

Re: Agentic Coding Recommendations

#80

Post by horsawlarway »

EdwardDiego wrote: post #13

"Write the simplest code you can, so the dumb AI can understand it" isn't the massive sell I was expecting. I wonder how that interacts with his previous post? https://lucumr.pocoo.org/2025/2/20/ugly-code/

Honestly, I find this approach to be useful pretty much anytime you're working with other people as well.

There are absolutely times to be extremely focused and clever with your code, but they should be rare and tightly tied to your business value.

Most code should be "blindingly obvious" whenever possible.

The limit on developers isn't "characters I can type per minute" it's "concepts I can hold in my head."

The more of those there are... The slower you will move.

Don't create more interfaces over the existing ones, don't abstract early, feel free to duplicate and copy liberally, glue stuff together obviously (even if it's more code, or feels ugly), declare the relevant stuff locally, stick with simple patterns in the docs, don't be clever.

You will write better code. Code shouldn't be pretty, it should be obvious. It should feel boring, because the hard part should be making the product not the codebase.

Post reply on HN