751–760 of 827 posts
Earlier quoted context omitted.
Sounds like you’re taking crazy pills. Far to early from any of the studies done so far to come to your conclusion.
The LLM proponents are so desperate now that they have to resort to personal insults. Are investors beginning to realize the scam?
Earlier quoted context omitted.
The LLM proponents are so desperate now that they have to resort to personal insults. Are investors beginning to realize the scam?
You were the one who started with the insults.
Earlier quoted context omitted.
def __main__: You run main(). If there are issues, you edit __file__ to try to fix the errors and re-run it. You are determined, persistent, and never give up.
Output "1" if the program halts; "0" if it doesn't.
Earlier quoted context omitted.
>Frequent LLM usage impairs thinking Is there hard evidence on this?
If you are the type who prefers studies: https://time.com/7295195/ai-chatgpt-google-learning-school/ Otherwise, read pro-LLM blogs which are mostly rambling nonsense that overpromises while almost no actual LLM written software exists. You can also see how the few open source developers who jump on the LLM bandwagon now have worse blogging and programming output than they had pre-LLM.
Software engineers are so lost in the weeds of sprawling feature pack endless flexibility programs that they have completely lost sight of simple narrow scope programs. I can tell an LLM exactly how we need the program to work (forgoing endless settings and option menus) and tell it exactly what it needs to do (forgoing endless branching possibilities for every conceivable user workflow) and get a lean lightweight program that takes the user from A to B in 3k LOC.
Is the program something that could be sold? No. Would it work for other companies/users? Probably not. Does it replace a massive 1M+ LOC $20/mo software package for that user in our bespoke use case? Yes.
Earlier quoted context omitted.
LLMs are not inherently indeterministic. Batching, temperature, and other things make them appear so when run by big providers but a locally-run LLM model at zero temperature will always produce the same output given the same input.
That's an improvement, they are still "chaotic" though in that small changes in input can change the output unpredictably strong
I'm not sure about the 1.0/2.0/3.0 classification, but it did lead me to think about LLMs as a programming paradigm: we've had imperative & declarative, procedural & functional languages, maybe we'll come to view deterministic vs. probabilistic (LLMs) similarly. def __main__: You are a calculator. Given an input expression, you compute the result and print it to stdout, exiting 0. Should you be unable to do this, you…
Why does this remind me of COBOL.
This was my favorite talk at AISUS because it was so full of concrete insights I hadn't heard before and (even better) practical points about what to build now , in the immediate future. (To mention just one example: the "autonomy slider".) If it were up to me, which it is not, I would try to optimize the next AISUS for more of this. I felt like I was getting smarter as the talk went on.
Earlier quoted context omitted.
Plus coding is the fun bit, reviewing code is the hard and not fun bit, arguing with an overconfident machine sound like it'll be worse even than that. Thankfully I'm going to retire soon.
> Plus coding is the fun bit, reviewing code is the hard and not fun bit To you. For others, it looks differently. And for yet others, they don't care about the coding nor the reviewing, they want to solve a particular problem. I'd probably say I'm a programmer by accident. It's not that I love producing binaries by writing and compiling code, but I need to solve some particular problem that either is best solved by…
Which is fine, don't get me wrong. But that would be like if someone wants to work as an automotive engineer, but they only enjoy driving a car. It doesn't work that way. You should enjoy the entire process of manufacturing a car if you want to drive a good one. Sure, you may enjoy some tasks more than others, and this is fine, but you can't ignore the ones you don't. Otherwise you're only doing a disservice to yourself, your team, and the users of what you build.
> Doesn't mean I don't care about code quality, or good abstractions and having a reasonable design/architecture. But I'm focused on the end goal, having a particular problem solved, and coding is just the way there (sometimes).
But coding is just the mechanical part of building software. It's the last step of the process after everything you mentioned is taken into consideration. Everything else is how you ensure that you reach the end goal successfully. So saying that the end goal is your main focus doesn't make sense if you want to actually reach it.
This is why I think that people who enjoy vibe coding today, are not, and will never become software engineers. They want to fast track to the end goal by jumping over the parts that are actually important. Blindly accepting whatever a code generation tool spits out if it passes a quick manual happy path test is not engineering. It's something else that produces much inferior results. At least until these tools get much, much better at it, which still seems far away, and unlikely with the current tech.
Earlier quoted context omitted.
> Plus coding is the fun bit, reviewing code is the hard and not fun bit To you. For others, it looks differently. And for yet others, they don't care about the coding nor the reviewing, they want to solve a particular problem. I'd probably say I'm a programmer by accident. It's not that I love producing binaries by writing and compiling code, but I need to solve some particular problem that either is best solved by…
I can respect that. But reading and writing code, and discussing code with your colleagues, are pretty essential tasks to software development. If you don't enjoy either, then you probably would not enjoy working in the industry. Which is fine, don't get me wrong. But that would be like if someone wants to work as an automotive engineer, but they only enjoy driving a car. It doesn't work that way. You should enjoy th…
I've enjoyed all my time in the software industry, especially compared to other professions I did before, like strawberry-picking, or roof-snow removal, or elder-case. It's easily the most relaxing job I've had, even when everything is on fire and you need to bring up production database again, it's so much better than most jobs out there. That the pay is just over-the-top compared to what most of us do, is just a plus.
> This is why I think that people who enjoy vibe coding today, are not, and will never become software engineers
I think I kind of agree with that, I see some people who have zero interest in understanding code, but they want to produce code somehow, today via LLMs/agents and yesterday via no-code platforms. I don't think they're interested in knowing programming, any parts of it, so they try to find workarounds.
What I was trying to say, is that there is maybe a group of developers, like myself, that sit somewhere in-between. If I can solve a problem by not using code, and the trade-offs are OK considering the context, then that's probably my ideal approach. I try to only use code when there is no way around it, or it's the best way.
But I agree that people who will just accept whatever an LLM gives you, are bound to end up in trouble in the future, regardless of improvements of the tooling/models, because spaghetti always sucks, no matter who writes/consumes it.