Live data from Hacker News

The solution might be cancelling my AI subscription

thoughts.hmmz.org

101–110 of 252 posts

Re: The solution might be cancelling my AI subscription

#101

Earlier quoted context omitted.

Once you reach a certain skill level you really didn’t ever visit SO anymore. I basically just live in Postgres, Redis, Ruby and Rails documentation. Still do.

SO was just an example. If you try to tell me you've never copied/pasted code before I know you are lying.

I don't think I was ever able to straight copy and paste from SO, everything needs adaptation, and code can often be simplified. And you need to understand your code. SO was useful, but nothing could be used copy pasted.

Maybe this is not the case if you are doing a dozen throwaway websites, but for anything serious that is an absolute requirement. I work in hard realtime safety critical code, think things like brake controllers, medical devices, auto pilots, etc. In my case industrial control systems. You need to have full control and documentation for your development process.

Re: The solution might be cancelling my AI subscription

#102

Earlier quoted context omitted.

Once you reach a certain skill level you really didn’t ever visit SO anymore. I basically just live in Postgres, Redis, Ruby and Rails documentation. Still do.

SO was just an example. If you try to tell me you've never copied/pasted code before I know you are lying.

I agree with the notion it's an age thing, but not because I am old, but because the tools are different. When I was learning to program as a kid I blindly 'copied and pasted' from computer magazine. I typed everything in, not understanding what I was doing, and made mistakes. Then came the tedious problem of figuring why the code didn't work. What was the syntax error? Why was it wrong? Why did the computer crash when I poked the wrong memory address?

I learned to debug and built comprehension by typing it in, and built it as a practice. Later in life and career I learned the value of transcription rather than copying and pasting because it at the very least forced me to read and write what I was copying, and built the base and familiarity I needed to learn from what I was copying.

That extends to how I use AI today. I use AI tooling to explore the concept of what I am building, use spec based designs to build solid outlines, and scope individual coding sessions, so that even when I use AI to build it, I have read, edited, and managed the design, and when I run into parts that I don't consider boilerplate I treat it the same way, transcribe what was attempted to understand why it was failing, and make sure I understand what the AI is doing that I haven't done before.

Re: The solution might be cancelling my AI subscription

#104

Earlier quoted context omitted.

Where do you think those bugs reports for gcc and others come from? Some people do look at the assembly coming out of the compilers. Currently the openbsd mailing list for port is currently going through a clang update and one of the main point is looking at all the packages that failed to build. I even took a long look at the usb stack and the audio subsystem of OpenBSD because of an issue I was having with my DAC.

I literally do packaging for a living and you are misunderstanding my point. Most people just take a binary and run it. There's no analysis of the assembly code. You might profile it and bench it after the fact but no one is sitting there looking at the assembly line by line unless there's a very very good reason and frankly LLMs are better at that type of investigative work. I know because I've been investigating so…

What's the reliability of compilers this day? How likely for a bug to be in your code and not in the compiler? I think it's close to 99.99...

So when you have a bug and a core dump, you can quickly load it in debugger, see the stack frame and then theorize a model for the bug to happen. If after verifying the source and having complete confidence that it's good, then you start looking at the assembly, most likely while single stepping with the debugger. But you rarely get to that point, because 99.99... it's your code.

That reliability is what AI tooling is lacking. It's exhausting monitoring the output because errors can be as simple as a minus character or the wrong comparison operator.

Re: The solution might be cancelling my AI subscription

#105
post #33

Earlier quoted context omitted.

I work with AI everyday, despite what many people suggest there is so little to learn. After a couple of hours you are good to go. You don't even need gstack.

This is patently false. I work with and on AI every day at multiple levels of the stack, and every day I'm learning massive new swathes of information. I'm honestly shocked how deep the field goes and how much more effective you can be with time. The floor is falling and the ceiling is rising and the gap between them is widening every day.

Maybe it depends on the task, but the biggest productivity gains are from boiler plate generation, and there it's as easy as "generate me the boiler plate". Even if you can learn some very specific workflows today they would be model dependent and mostly obsolete within a month or two.

Re: The solution might be cancelling my AI subscription

#106
post #57
post #43

Earlier quoted context omitted.

Some people, if not most, will at some point look back (and forward) in their life and wonder if they made anything out of it. And what they are really asking is "how much of an impact on others have I made?" YMMV

and marketing something is the answer?

Indeed, if you make something that improved many people’s lives, you‘ll probably see it as a great success.

That often requires marketing it.

Re: The solution might be cancelling my AI subscription

#107
I don't thing the problem is AI, but the mindset and trainning. I have probably as many or more AI projects that this man has but they are extremely useful, even if most of them I won't even sell.

This is like a kid playing videogames instead of studying, you take the console away and force the kid in front of a book and the kid will spend most of his time looking at the wall and dreaming.

I am engineer with very deep programming background that have managed people, with real experience in the real world.

One of the best things about AIs is that you can test crazy ideas and create prototypes very fast. Only one in a hundred will work great in the real world, but you have to create the 100 before to know.

Creating the 100 before AI was extremely expensive, and took so much time.

For me it is liberating and gives me focus because I can spend so little time testing prototypes and spend real time in what is really important and works.

This is something I learned from game developers: If you are going to create a game, you spend a weekend testing the dynamics and the gameplay of your prototype to know if is is fun. You use boxes, no textures, no complex sounds of music.

Then if it works and is is so fun, you create the game! You can spend 2 years creating the game after that.

You don't spend two years doing a Game only to realise later that is not fun, and you either spend 3 more years or abandon it at this moment.

Re: The solution might be cancelling my AI subscription

#109

Earlier quoted context omitted.

I literally do packaging for a living and you are misunderstanding my point. Most people just take a binary and run it. There's no analysis of the assembly code. You might profile it and bench it after the fact but no one is sitting there looking at the assembly line by line unless there's a very very good reason and frankly LLMs are better at that type of investigative work. I know because I've been investigating so…

What's the reliability of compilers this day? How likely for a bug to be in your code and not in the compiler? I think it's close to 99.99... So when you have a bug and a core dump, you can quickly load it in debugger, see the stack frame and then theorize a model for the bug to happen. If after verifying the source and having complete confidence that it's good, then you start looking at the assembly, most likely whi…

I'm usually compiling other people's code. Hitting that 1 in 100,000 issue in run time and then having to come up with patch. And then have to make sure it's okay in arm and amd64. The bug I'm thinking of is decidedly a human output and the LLM is cleaning up the slop.

Re: The solution might be cancelling my AI subscription

#110

Earlier quoted context omitted.

I don't really see this as analogous. Yes, you do choose an abstraction level to operate at, I rarely think in terms of transistors, or even gates (which by your logic an assembly programmer should do). But I often do think across adjacent abstraction levels, because abstractions are (varying levels of) leaky. Modern compilers are after many decades good enough and modern computers fast enough that it is rare that I…

My lived experience over the past few months is proving you wrong. I started with your position and have since been able to see how good the tools are when properly used. I've also noticed a huge gap in ability among engineers and I think the gap is widening. My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly ann…

> My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly annoyed at the idea of having to pay for these things so they lash out.

At my last job the employer paid for OpenAI access for all of us.

Baby sitting an LLM is not my idea of meaningful use of time. And reviewing code that someone else had an LLM spew out even less so.

I am not lashing out because I don’t have access to LLMs. I had access and I did try it plenty.

Post reply on HN