Hacker News Reader

Comment by polotics | Hacker News Reader

This appears to me to be a surprisingly low-effort article. Nothing about managing context length and starting tasks from a good context, managing .md files and structuring repos, very anthropomorphising which does not help, nothing about tools to use to build the right context, no comparison of different approaches, what kind of MCP and/or RAG to get agents to look at documentation.

View on HN

That's kind of the whole point. Setting up a few MCPs etc. is really a minor thing in the grand scheme of things. Sure, I have setup context7, Sequential Thinking, etc. and my Claude.md has a lot of details in it, but that only improves the accuracy so much. My whole point is that if the mindset is "I need this to be very accurate for it to work", then you're already putting too much effort into it. I personally have not found any of that time worth it. For any PR I had to put effort into, I could have done it quicker myself. So I learned those things and they just didn't have a payoff for my work. They did really well in some things like front end development, devops, and stuff of that sort, but if it's the normal kind of problem that is my "here's my actual hard problem of the day", i.e. something where I would need to start white boarding a new algorithm and semi-prove some numerical stability result before throwing code, the LLMs just fail to ever come up with anything new enough to get a solution.

But, slamming down commands for it on only easy problems in order to get 90% of a PR done and just finishing it yourself? That can get you 6 PRs in instead of 3, where you did the hard 3 and just looked at the transcripts for another 15, and tossed all but the 3 that looked good. Using Claude like that takes about half an hour out of your day and you get a good benefit, and that is what I am pointing to as a very useful approach.

I personally don't think any amount of MCP servers will make "Claude, find me a novel algorithmic improvement in this space and code it up" work, but hey if that works for you that's great. But reviewing and checking the proofs would likely make it not worth it for what I'm doing.

ok you're right, i got fooled by the title: "A Guide to Gen AI / LLM Vibecoding for Expert Programmers"

> They did really well in some things like ... devops

Did they, though? I ask because the vast majority of people touting LLM as a huge win usually seem to speak from a.. DK-heavy perspective. As in, the bulk of their profession experience hasn't actually been doing the subject they're gushing about the LLM crushing.

So I ask you, what is your level of devops experience to make such a dismissive, sweeping statement? I am pointedly inquiring about my own area of expertise, in case that wasn't clear.

I mean this for simple devops tasks, like if you need it to write you a Bash script that will clean out some empty caches or something it will one shot it most of the time. And for figuring out standard tasks like setting up deploy keys for some new doc system or updating the make files to handle some new build dependency. I still have devops engineers for anything difficult, but they get pestered with a lot less things they would find trivial that the rest of the teams would have asked them for help on before.

The article clearly isn't directed at how expert programmers are 'supposed' to use AI, though we see at least one of those a day on the front page of HN now. The first paragraph makes it pretty obvious that the author is trying to convince people who have completely disregarded AI, for one reason or another, to give it another try in a more meaningful way. Telling the reader how the author configures his AI isn't going to convince those people, as they likely are already very aware of how these tools 'work' the problem is in the 'how to use them' department which has nothing to do with what MCP tool you're using.

Reply on news.ycombinator.com