←back to thread

Nobody knows how to build with AI yet

(worksonmymachine.substack.com)
526 points Stwerner | 1 comments | | HN request time: 0s | source
Show context
lordnacho ◴[] No.44616832[source]
I'm loving the new programming. I don't know where it goes either, but I like it for now.

I'm actually producing code right this moment, where I would normally just relax and do something else. Instead, I'm relaxing and coding.

It's great for a senior guy who has been in the business for a long time. Most of my edits nowadays are tedious. If I look at the code and decide I used the wrong pattern originally, I have to change a bunch of things to test my new idea. I can skim my code and see a bunch of things that would normally take me ages to fiddle. The fiddling is frustrating, because I feel like I know what the end result should be, but there's some minor BS in the way, which takes a few minutes each time. It used to take a whole stackoverflow search + think, recently it became a copilot hint, and now... Claude simply does it.

For instance, I wrote a mock stock exchange. It's the kind of thing you always want to have, but because the pressure is on to connect to the actual exchange, it is often a leftover task that nobody has done. Now, Claude has done it while I've been reading HN.

Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.

Now I know what you're all thinking. How does it not end up with spaghetti all over the place? Well. I actually do critique the changes. I actually do have discussions with Claude about what to do. The benefit here is he's a dev who knows where all the relevant code is. If I ask him whether there's a lock in a bad place, he finds it super fast. I guess you need experience, but I can smell when he's gone off track.

So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.

What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.

replies(15): >>44616871 #>>44616935 #>>44617102 #>>44617254 #>>44618137 #>>44618793 #>>44621101 #>>44621200 #>>44621741 #>>44621995 #>>44622452 #>>44622738 #>>44623119 #>>44624925 #>>44624959 #
dangero ◴[] No.44622452[source]
Have you had the realization that you could never go back to dealing with all the minutia again?

LLMs have changed me. I want to go outside while they are working and I am jealous of all the young engineers that won’t lose the years I did sitting in front of a screen for 12 hours a day while sometimes making no progress on connecting two black boxes.

replies(2): >>44622639 #>>44624737 #
lelanthran ◴[] No.44622639[source]
Serious question: have you considered that dealing with all that minutiae and working through all that pain has made you capable to have the LLM write code?

Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.

They have all learned how to.micromanage an LLM instead.

replies(1): >>44622772 #
NitpickLawyer ◴[] No.44622772[source]
> Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.

I have heard a version of this plenty of times, and it was never correct. In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks". Well, bob, we did, the whole field moved to color coded anti-stupid design, and we figured it out.

Then I heard it about IDEs. Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.

Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?

... same old, same old.

replies(3): >>44622910 #>>44632869 #>>44633492 #
lelanthran ◴[] No.44622910[source]
Have you also heard about calculators?

Every single finance person uses a calculator. How effective do you think a person in any aspect of finance would be if they had never learned what multiplication is? Would they perform their job adequately if they don't know that `X * Y` is `X repeated Y times`?

IOW, if you gave a finance person (accountant, asset manager, whatever) a non-deterministic calculator for multiplication, would you trust the person's output if they never learned what multiplication is?

This is the situation I am asking about; we aren't talking about whether deterministically automating something that the user already knows how to do is valuable, we're talking about whether non-deterministically generating something that the user is unable to do themselves, even if given all the time in the world, is valuable.

All those examples you give are examples of deterministic automation that the user could inspect for accuracy. I'm asking about a near-future where people managing your money have never learned multiplication because "Multiplication has been abstracted away to a tool that gets it right 90% of the time"

replies(3): >>44622987 #>>44623138 #>>44624783 #
1. MITSardine ◴[] No.44624783{4}[source]
If I may play the devil's advocate, nothing is deterministic. A neutrino could cause a bit flip in your calculator. More commonly, the lower abstractions we build upon without knowing their innards can have bugs. Even the most popular compilers (say, g++) have bugs, for instance. I am personally incapable of fixing a bug within gcc, despite the tool being a vital requirement of my work.

IMO the dichotomy should not be deterministic/stochastic, but proved/unproved reliable. gcc has been shown reliable, for instance, so I don't need to know whether it was built by deterministic (clever engineers) or stochastic (typewriting monkeys) processes. I'm certain the former are more efficient, but this is ultimately not what makes the tool valuable.

As a bit of an artificial example, there's stochastic processes that can be proved to converge to a desired result (say, a stochastic gradient descent, or Monte-Carlo integration), in the same way that deterministic methods can (say a classic gradient descent or quadrature rules).

In practical cases, the only proof that matters is empirical. I write (deterministic) mathematical algorithms for a living, yet they very rarely come out correct on first iteration. The fact there is a mathematical proof that a certain algorithm yields certain results lets me arrive at a working program much faster than if I left it to typewriting monkeys, but it is ultimately not what guarantees a valid program. I could just as well, given enough time, let a random text file generator write the programs, and do the same testing I do currently, it would just be very inefficient (an understatement).