This isn’t a bad thing? Kids nowadays have the attention span of puppies. It’s been shown extensively that doomscrolling, switching context every 30s isn’t good for the brain.
I'm so happy someone else says this, because I'm doing exactly the same. I tried to use agent mode in vs code and the output was still bad. You read simple things like: "We use it to write tests". I gave it a very simple repository, said to write tests, and the result wasn't usable at all. Really wonder if I'm doing it wrong.
I’m not particularly proAI but I struggle with the mentality some engineers seem to apply to trying.
If you read someone say “I don’t know what’s the big deal with vim, I ran it and pressed some keys and it didn’t write text at all” they’d be mocked for it.
But with these tools there seems to be an attitude of “if I don’t get results straight away it’s bad”. Why the difference?
There isn't a bunch of managers metaphorically asking people if they're using vim enough, and not so many blog posts proclaiming vim as the only future for building software
I’d argue that, if we accept that AI is relevant enough to at least be worth checking, then dismissing it with minimal effort is just as bad as mindlessly hyping the tech.
It never broke into the workplace like measuring AI use among your employees. Nobody's asked me about how I've used vim keybinds to improve the company's growth in a performance review.
I don't understand how to get even bad results. Or any results at all. I'm at a level where I'm going "This can't just be me not having read the manual".
I get the same change applied multiple times, the agent having some absurd method of applying changes that conflict with what I say it like some git merge from hell and so on. I can't get it to understand even the simplest of contexts etc.
It's not really that the code it writes might not work. I just can't get past the actual tool use. In fact, I don't think I'm even at the stage where the AI output is even the problem yet.
>I don't understand how to get even bad results. Or any results at all. I'm at a level where I'm going "This can't just be me not having read the manual".
>I get the same change applied multiple times, the agent having some absurd method of applying changes that conflict with what I say it like some git merge from hell and so on. I can't get it to understand even the simplest of contexts etc.
That is weird. results have a ton of variation, but not that much.
Say you get a claude subscription, point it to a relatively self contained file in your project, hand it the command to run relevant tests, and tell it to find quick win refactoring opportunities, making sure that the business outcome of the tests is maintained even if mocks need to change.
You should get relevant suggestions for refactoring, you should be able to have the changes applied reasonably, you should have the tests passing after some iterations of running and fixing by itself. At most you might need to check that it doesn't cheat by getting a false positive in a test or something similar.
Is such an exercise not working for you? I'm genuinely curious.
> I'm at a level where I'm going "This can't just be me not having read the manual".
Sure it can, because nobody is reading manuals anymore :).
It's an interesting exercise to try: take your favorite tool you use often (that isn't some recent webshit, devoid of any documentation), find a manual (not a man page), and read it cover to cover. Say, GDB or Emacs or even coreutils. It's surprising just how much powerful features good software tools have, and how much you'll learn in short time, that most software people don't know is possible (or worse, decry as "too much complexity") just because they couldn't be arsed to read some documentation.
> I just can't get past the actual tool use. In fact, I don't think I'm even at the stage where the AI output is even the problem yet.
The tools are a problem because they're new and a moving target. They're both dead simple and somehow complex around the edges. AI, too, is tricky to work, particularly when people aren't used to communicating clearly. There's a lot of surprising problems (such as "absurd method of applying changes") that come from the fact that AI is solving a very broad class of problems, everywhere at the same time, by virtue of being a general tool. Still needs a bit of and-holding if your project/conventions stray away from what's obvious or popular in particular domain. But it's getting easier and easier as months go by.
FWIW, I too haven't developed a proper agentic workflow with CLI tools for myself just yet; depending on the project, I either get stellar results or garbage. But I recognize this is only a matter of time investment: I didn't have much time to set aside and do it properly.
I agree to a degree, but I am in that camp. I subscribe to alphasignal, and every morning there are 3 new agent tools, and two new features, and a new agentic approach, and I am left wondering, where is the production stuff?
Certainly, every tool is supposed to make our work easier or more productive, but that doesn't mean that every tool is intuitive or easy to learn to use effectively or even to use it at all.
Certainly, but aren't AI tools supposed to be intuitive and easy to use because we can communicate with them in natural language?
With VIM or Emacs I am supposed to know what Ctrl-X does. But with AI tools (ideally) I should be able to ask AI (in English) to edit the document for me?
Maybe the reason we can't do it that way is that, "We're not there yet"?
Honestly IMO it's more that I ask for A, but don't strongly enough discourage B then I get both A, B and maybe C, generally implemented poorly. The base systems need to have more focus and doubt built in before they'll be truely useful for things aside from a greenfield apps or generating maintainable code.
You didn't actually just say "write tests" though right? What was the actual prompt you used?
I feel like that matters more than the tooling at this point.
I can't really understand letting LLMs decide what to test or not, they seem to completely miss the boat when it comes to testing. Half of them are useless because they duplicate what they test, and the other half doesn't test what they should be testing. So many shortcuts, and LLMs require A LOT of hand-holding when writing tests, more so than other code I'd wager.
There are a lot of comments on HN and other places breathlessly gushing about agents totally doing everything end to end, so I couldn't blame someone new to this space for naively assuming that agents would be able to handle a well-bounded problem such as test coverage reasonably well.
> naively assuming that agents would be able to handle a well-bounded problem such as test coverage reasonably well.
We haven't figured out a way for humans to do that well :P I still see people arguing about "80% test coverage is obviously better than 70%" and similar dumb sentiments that completely misses the point.
But agree with the first part, LLMs are massively oversold and it's hard to blame users for believing them. Tempered expectations as always win.
No, that was an exaggeration. The prompt was decent. I explained the point of the repository, that I wanted full coverage with tests, that it could keep going until it worked. Maybe that was still not enough. With how others talk about it, I must be missing something.
For tests, you need to be precise about what it should test, how it should test it, and what the assertions should be, otherwise you'll mostly get trash, they're exceptionally horrible at writing tests. Which makes sense, most programmers are too, but given the importance of correct tests, it's probably the part that needs to most human handholding right now.
“Write tests“ may not be enough; provide it with a test harness, and instruct it to “write tests until they pass “. Next would be “your feature isn’t complete without N% coverage”. These require the ‘agentic’ piece, which is at its simplest some prompts run in a loop until an exit condition is met.
No, you have similar experience as a lot of people have.
LLMs just fail (hallucinate) in less known fields of expertise.
Funny: Today I have asked Claude to give me syntax how to run Claude Code. And its answer was totally wrong :) So you go to documentation… and its parts are obsolete as well.
LLM development is in style “move fast and break things”.
So in few years there will be so many repos with gibberish code because “everybody is coder now” even basketball players or taxi drivers (no offense, ofc, just an example).
Damn, that’s a pretty disappointing statement. Some parts are correct but then he goes completely overboard. After everything that has been happening the past year with the new administration it’s hard to keep supporting this as a European.
I found it quite badly written, and have no clue what they actually did and what the impact was. We exposed money flows, and now potholes are being filled. What?
Maybe I read it to quickly, but what they are doing is quite complex. The medium he's using to explain it might not be the best one for his skillset.
Isn’t it that the current market price of NVDA was based on the amount of chips they need to sell? Because to train and run models you need so many GPU’s. Now that deepseek is showing you need less GPU’s to train and run it, the value of NVDA lowers since they won’t sell as much.
Parent's comment was changed enough that my comment is meaningless. They previously said that you don't need NVIDIA for deepseek. I'll leave mine alone.
We had the same issue, but it was over by 10-20% in our case. Discussed this with them multiple times, and the last response I got was:
"I've checked in with our engineering teams, and we unfortunately don't yet have a fix or timeline to share here, though we have made additional progress on scoping a path forward. It's extremely complex on our end, as existing data models don't have the required information in place to make the change here, and we'd need to scope how to add that and backfill data (which we're approaching, but again, no timeline to share as of now)."
Obviously I don't know anything about them internally, but if I can export the data as a CSV-file, and then calculate the MRR myself in GSheets, then what data needs to be backfilled? The data is already available to properly calculate it.
My interpretation of backfilling here is that they need to architect the data in a different way to be able to have all the information needed to calculate the MRR correctly. Then once the data is modelled how they need it, they have to backfill the new model. Basically like your export to csv step. I'm sure the data that fills your csv export is coming in from a dozen different tables and sources.
As others have said, you'll need to talk to him. And focus on what does he want, and what does he think is fair. He can't expect to keep his share of the company, while also bailing on you, but most people don't think like this anyway. If your working relation was good, and he wants the company to succeed, he won't play hardball. Which means that you also don't need to get into the conversation with your guard up. Just talk to him, and be a decent human being.
I agree that saying “Microsoft did it already” is a silly response to something that is just a positive to gaming. But your example of Nintendo doesn’t really mean anything when Nintendo didn’t put a lot of effort in supporting disabled people the last generations.
I applaud Nintendo for doing this for the NES, but where are they today?
>But your example of Nintendo doesn’t really mean anything when Nintendo didn’t put a lot of effort in supporting disabled people the last generations.
Because it's not an example of Nintendo being good, it's an example of why this reductive argument is meaningless.
reply