391–400 of 667 posts
Earlier quoted context omitted.
Let me translate this for you: "I have not spent the time cultivating the soft skills necessary to leverage this tool successfully therefore it's the tool that sucks."
No one in this chain said it sucks. Any sort of criticism towards LLM workflows is constantly met with these kinds of absurd statements. I've never seen any other tool with this kind of mentality from proponents
Earlier quoted context omitted.
I use the app every day and I am confident in the quality. I will launch it by the end of August. After ~4 months of hard work.
If it’s 4 months of hard work, then it’s not like you’re blindly doing it as the top commenter mentioned.
My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.
The limitation here is mostly that the model does not know what looks and feels good.
With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.
Earlier quoted context omitted.
The useless suggestions are exhausting. One of my co-workers uses Claude for all asynchronous communication, including Slack messages, Jira comments, code reviews, and emails. Every single message from him, literally every time he communicates, it's a massive wall of text, overflowing with scope-creep suggestions like nothing I've ever seen before. It's impossible to ask him a simple question and get a simple answer.…
What have your or their manager said about this? About any or all of (a) slowing everyone else down with crap, (b) wasting company resources on generating crap, (c) not doing anything that a CI integration couldn't trigger the AI to do itself?
And with hiring effectively frozen there is not even an incentive to let go of those people because they will not be replaced - they may have contributed little overall (routine tasks, oncall weeks) and now contribute 10x more spam while before they would not even try to investigate an issue, but we don't have the cycles to allocate that to someone else. And every time you tell them something they try to gaslight you by telling you they're trying to learn and you're being too aggressive.
I've become so frustrated by seeing claude-isms in slack or in emails it has become impossible for me to use it to work on my personal projects and I'm moving over to codex. Maybe it's time to try pi and some chinese models, definitely I need a break from this madness.
Earlier quoted context omitted.
Gotcha, so no.
You don't need a "blog post." You need experience managing projects, tracking progress, coordinating conversations, mentoring less experienced engineers, etc. That experience comes with practice and time. If you really need something to latch onto, there's plenty of educational material available about how to be an effective scrum master. Start there.
Some AI skeptics paradoxically insist humans are irreplaceable and then get almost mad(?) when you discuss how humans are necessary in the loop. At least that's my interpretation of what is going on, it's hard to tell.
When building with LLMs I'm mostly product manager and QA, the whole task is having the judgement to evaluate and correct course. You can share advice but it's not a copy-paste situation where one set of prompts/harnesses/whatever solve all your problems forever. They have to be adjusted for a particular situation.
Earlier quoted context omitted.
Really? Explain please haha
I'm not that guy but I've advised end users submitting tickets to prompt inject the importance of the ticket so that it gets triaged higher by lazy people only using AI and not actually reviewing. Not sure how efficacious but I know the reviewer is just relying on the AI decision.
If you have to lie to get your tickets fixed, that sounds like either you're bad at explaining why things are important, or you're working on things you shouldn't be.
Earlier quoted context omitted.
I don't know, this more and more feels like a sentiment projected on to people than anything real these days.. Like even in that linked thread, is personal offense like you lay out here really were you can place Laurent Pinchart's push back? You don't read anything else there at all? And either way, what, we are going to keep this line going for another 5 years? Aren't you bored?
> You don't read anything else there at all? The citation was in support of the post above mine and was incidentally a link to a mailing list. I did not read the mailing list threads out of personal interest, admittedly. I think it's a particularly bad way to communicate (took 15 years for me to figure it out), so I avoid them. > Like even in that linked thread, is personal offense like you lay out here Taking it per…
Earlier quoted context omitted.
You can very easily spot performance issues through code. Allocations are often visible, slower hash maps are often visible, loops are visible, etc.
No you can't.
I can see in the code when data layouts aren't optimal, and fix that.
There's a lot of optimizations that need more of a deep dive, but you can get a lot of gains by just reading and reasoning about your code/data.
EDIT: To add, there are cases were you specifically can't read code and understand performance issue, but you should first ask, is that because you just don't understand the APIs/Libs/tools you're using, or is it fundamentally difficult. For example, often at work I see people complain about their torch code being slow and needing to bust out a profiler, but often those people just don't understand how tensor operations work internally so of course they can't reason about the code and see the way they're using the lib is suboptimal.
Earlier quoted context omitted.
Linus: "it keeps finding embarrassing bugs" Linux Kernel: https://lore.kernel.org/all/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80Kzs... The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many. Some people didn't think we would see the day where that comparative human limitation was laid bare in simpler tasks than they expected. I believe older develo…
> The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many Lol! What about fuzzers, linters, typecheckers and formal tooling? There’s plenty of machine code evaluators that people do use because it’s better than relying on human skills. The issue is the actual report and the lack of information.
Earlier quoted context omitted.
It is moving so fast that your experience with older models is irrelevant today. Sorry. Claude Code, Fable 5, xhigh reasoning, allow it to run the full CI, end to end and benchmark, it will not make silly mistakes (or only occasionally). Also, be able to state what you desire. Have any docs or materials in the same directory so the model can reference it. For even better results: turn on speech recognition and braind…
I'm not saying I don't get any use out of them, fwiw. In a lot of ways they write perfectly fine code, I'm just saying without some guidance at the macro-level they lose the forest for the trees, that's all.
I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change. In fact, if it wasn't for the fact that it made making the actual changes I identified much e…
I had worked on some earlier deployment environments for a few models where we focused on one version of Triton and one runtime technology. Even upgrading to a newer Triton version was brittle, involving a lot of command-line changes at various phases. This was written mostly pre-Claude-getting-real-good. I decided that probably Claude had matured and was way better at understanding the particulars of AI-model-GPU-deployment-and-technologies. I worked with Claude to make the framework a much more lightweight wrapper, ignorant for the most part of a lot of the deployment internals.
After this refactoring and doing the first couple of models, it's quite amazing at how well Claude can figure things out. For any new model we now set up its "specialization" directory and its documentation subdirectory, point Claude at the proper AI-model files, point Claude to the sample non-optimized inference code and test data, and point Claude to a similar conversion we've done in the past. There a multi-layer class hierarchy dealing with various tiers. I ask Claude to explore the existing conversion/packaging, the model, any documentation that comes with it (a lot of times there are unexpected twists), the sample code, and the desired multiple use cases the model is meant to address, and the test data. Claude has been trained, I'm sure, on a lot of AI model conversion, so it's able to synthesize the full multi-stage conversion/deployment pipeline, come up with appropriate test cases for all the use cases involved. There are usually between 3 and 10 refinements after initial synthesis, fixing outright errors, refinemnts that the data-science team requests after playing with test deployments, etc. The options and pitfalls are vast, and without Claude each preparation likely would 10x or more longer. I just put most details in Claude's hands, and make sure the general framework is good enough to provide external uniformity. When all is working, it takes a couple of hours to make sure the documentation is good.
All this to say that at least for this domain, Claude / AI has been a game-changer and has sped up the process amazingly.