291–300 of 391 posts
Earlier quoted context omitted.
Flying drones is an interesting one, I guess you do have to drive the car out to site and set up the drone. But a lot of drone ops are waypointed, automatic flight. I can see a future in which the only thing the operator does is drive the drone van to site, hit the deploy button as the drone pops out the roof, and wait for it to return. Mission set up already by an LLM prompt back at the office.
I bet drone van is the next thing to be automated.
Earlier quoted context omitted.
You okay? This isn't a response I expect from people who are here for a productive discussion. I'm sorry that you are sick of hearing this, but I'm not responsible for making sure you only read what you find worthy of your own personal brand of respect. Instead of attacking someone for simply offering their point of view, in what appears to be a quasi-gatekeeping effort, maybe you should look inward and discover what…
I'm totally fine, just annoyed by how much this "try not to think too hard about the how and think more about the why and what"[0] is getting brought up every single time someone mentions why they prefer hand coding to vibe coding. At this point, it's being overstated, thus gives off less "this is why I use it" and more "come on, get onboard the hypetrain to dystopia or you're going to get left behind". It's hardly c…
then so is your opinion on the matter. this goes both ways. I can just as easily dismiss your commentary as "drive-by".
> Not really a statement of your drive, is it? More of a directive or suggestion.
Yeah, so was my initial comment. Merely a suggestion concerning view points, and how a shift in that can bring back some amount of joy.
You don't have the moral high ground here.
I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. In the past (before LLMs) it was already hard to keep up, but now it feels like there's 10x more things waiting at any given time, a…
> I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. I see a different type of pressure: I'm at a company that still is requiring everyone use LLMs with token leaderboards, time-spent…
Earlier quoted context omitted.
If solving jigsaw puzzles with claude will enable the creation of tools that help the people I want to help (students with disabilities), then I would use it for that, without feeling any guilt at all for doing so. Why should I regret that? Why should I care about your purity tests?
Nobody said you should? Some people merely enjoy programming more than engineering.
This is dishonest. Your quip was to imply that I'm reducing what is otherwise a fun activity to an automation, on the basis of a purity test.
> Some people merely enjoy programming more than engineering.
And I haven't said otherwise, so I'm not sure what point youre trying to make. My initial goal was to provide my own viewpoint on how to enjoy the process while taking advantage of modern tools, not to tell people they shouldn't enjoy programming more than engineering.
I've started feeling slightly physically ill when I read Opus output for hours straight. This article rings very true for me. I've started complaining about it with my team; at least have a personal style guide in your agent rules that eliminates emdashes, the "it's not X, it's Y"s, the long lists of modifiers before the noun, using the word "land" to mean finish, etc. I hope this is just a phase of adolescent LLMs.
" That's such a clever way to see things! Let's delve into that! " The bots (all of them) seem to show patterns of overuse of specific phrases, words, and punctuation. Some of those are the ones you mentioned. Another that I've been seeing lately is overuse of the term "gate", wherein: As a human, I know what a gate is. A gate is a thing that can be open, or that can be closed. It might be locked or unlocked. The pat…
Earlier quoted context omitted.
Feed it into an AI and ask it to adversarially criticize it, doc for doc, send back 30 responses in a zip folder, wipe hands on pants, return to HN.
Don't know if you are serious, but why become part of the problem? Why not just review a single document quickly, find an error which invalidates the document, and send it back saying "Policy paper 1 mentions X as being on the business plan for Y, it's not on the plan, please can you fix."
Unless you can write a good-sounding reason why it's on them to review a LLM output before sending it to you, they will outsources this reviewing to you, and it's a lot of reviewing.
Earlier quoted context omitted.
Then this falls into the exact same pit the OP mentioned, either you need to blindly trust that the LLM is generating tests that actually work, or you need extensive test coverage for your tests to ensure that your tests are actually testing.
It turns out that you don't actually need tests for your tests, because the code provides a baseline truth for the tests. You do, at some point, have to be epistemically sound enough to actually look for correctness in either the code, behavior, or tests. We unfortunately haven't fully unlocked completely solipsistic value generation yet. This is also part of why I like end to end tests that use actual UI flow, so I…
What do you mean by "be epistemically sound enough"?
You are using it as if to say "if your code is grounded in sound abstractions, you'll be fine and tests will therefore generate successfully" but preface that claim with "the code provides a baseline truth for the tests". The latter does not follow from the former, and it also does not lift the burden of responsibility away from the programmer - which is where my doubts on test generation stem from in the first place.
Additionally, what is "completely solipsistic value generation"?
You reference it like a perk in a skill tree, but to my ears "generating completely solipsistic values" seems like a way of describing AGI with a philosophical wording instead of just saying AGI.
I’ve had it three times already in the last 2 years and it is something real. Dizziness and depressive swings is the first that comes, then comes memory loss and finally trouble with speech. At this point you should stop risking to burn your central cognitive capacity. Be advised. Note: myself a passionate Claude code user with multi agent parallel approach to dev. Plus 30 yrs of various oldskool dev experience. My b…
Earlier quoted context omitted.
I see this get mentioned a lot but I still am skeptical that AI can generate tests we can trust more than any other code we know we cannot trust. Yes tests are conceptually isolated and that helps, but I've personally seen unit tests get generated that are semantically incorrect - that is, they test the structure of the code (e.g. they can check function output types and values), but they can't know _why_ the unit te…
You have to iterate on the tests, review and validate them, just like any other code, and if you generate a whole project's tests all at once the quality is abysmal, of course. I've been using a lot of old school data-driven testing techniques, where the harness is just code I review, and the data itself is e.g. json files and drives the system. I actually have a public (AGPL) example here: https://github.com/pgdogde…
Also you: > You have to iterate on the tests, review and validate them
Yes, "maintain" is not quite the same as "review", but the line is veeery fine. I find it really tiring to review masses of tests that an agent spews out.
Especially because I know what it has a tendency to write irrelevant/vacuous/useless tests. It's insane the amount of times I have told Codex to "write a test that reproduces the reported bug, SEE THE TEST FAIL, then implement a fix", only for it to guess an irrelevant test, not run it to see it fail, and implement a code change that has nothing to do with either the test or the actual bug.
I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. In the past (before LLMs) it was already hard to keep up, but now it feels like there's 10x more things waiting at any given time, a…
> I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. I see a different type of pressure: I'm at a company that still is requiring everyone use LLMs with token leaderboards, time-spent…