[deleted]
AI coding
171–180 of 299 posts
Re: AI coding
#172This is a more extreme example of the general hacker news group think about AI. Geohot is easily a 99.999 percentile developer, and yet he can’t seem to reconcile that the other 99.999 percent are doing something much more basic than he can ever comprehend. It’s some kind of expert paradox, if everyone was as smart and capable as the experts, then they wouldn’t be experts. I have come across many developers that beha…
This. I think his excellency in his own trade limited his vision for the 99% who just want to get by in the job. How many dev even deal with compiler directly these days? They write some code, fix some red underlines, then push, pray and wait for pipeline pass. LLMs will be gods in this process, and you can even beg another one if your current one does not work best.
[deleted]
Re: AI coding
#173Earlier quoted context omitted.
I expect much of this can be solved with better architecture: smaller, more independent components. Break large code bases up into independent libraries, and LLMs can work again because they need much less code in their context.
Suggesting I restructure my code base to work better with a non-deterministic black box feels like an instance of Conway’s law[1] that should be avoided. https://en.m.wikipedia.org/wiki/Conway%27s_law
You’re free to avoid it but maybe your competition will do it and may outpace you because of it. Conways law just states that architecture follows organizational structure so it’s only to be expected that ai generated software has an ai influenced architecture.
Re: AI coding
#174I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…
Per @vgr, LLMs are an old person’s technology. (I, too, am an old person.)
Re: AI coding
#175I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…
Yes! Once I've figured out that this problem is best solved using parser combinators, and that I have a good idea of how to model the transformation, I'm so glad I can delegate work to the LLM code gen and focus on the specification, test cases, corner cases, etc;
Re: AI coding
#176This post is such a cold take, and is going to age horribly. Self driving cars fail because of regulatory requirements for five nines reliability, and they're doing inference over a dynamic noisy domain. Autonomous engineering does not have these issues. Code doesn't need to be five nines correct, and the domain of inference is logical and basically static. If the AI agent/coding companies didn't have their heads up…
This sounds like you haven't used one of these coding agents.
Re: AI coding
#177I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me. Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work. It only takes basic english to produce these results, plus complaining to the AI agent that "The GUI is ugly and overcrowded. Make it look better, and dark mode." Want specs? "include a specs.md" This isn't a 20%…
The crucial part is security. If the apps runs locally it doesn’t matter, if it‘s connected to the net it could be the seed for the next Mirai bot network.
Also design. All the vibe coded apps always look like absolute ass.
Re: AI coding
#178I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…
I love AI for speed running through all the boring stuff and getting to the good parts. In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of tim…
Yes I can see why some devs might prefer the safety of the boring and the familiar stuff. But the employers aren’t going to care about that. They’re going to hire and retain the devs who are more productive in the new era.
On the flip side, there have been lots of times where I personally didn’t have a lot of time to deeply research a topic (read papers, build prototypes of different ideas, etc) due to lack of time and resources. If all of the boring stuff is gone, and building prototypes is also 3x faster maybe what will end up happening is we can now use all of this free time to try lots of different ideas because the cost of exploration has been lowered.
Re: AI coding
#179This post is such a cold take, and is going to age horribly. Self driving cars fail because of regulatory requirements for five nines reliability, and they're doing inference over a dynamic noisy domain. Autonomous engineering does not have these issues. Code doesn't need to be five nines correct, and the domain of inference is logical and basically static. If the AI agent/coding companies didn't have their heads up…
This sounds like you haven't used one of these coding agents.
I'm piloting a swarm of coding agents 12+ hours a day, friend.
Re: AI coding
#180Earlier quoted context omitted.
I think there are two kinds of uses for these tools: 1) you try to explain what you want to get done 2) you try to explain what you want to get done and how to get it done The first one is gambling, the second one has very small failure rate, at worst, the plan it presents shows it's not getting the solution you want it to do.
The thing is to understand that a model has "priors" which steer how it generates code. If what you're trying to build matches the priors of the model you can basically surf the gradients to working software with no steering using declarative language. If what you want to build isn't well encoded by the models priors it'll constantly drift, and you need to use shorter prompts and specify the how more (imperative).
In my experience, you need shorter prompts and steering it constantly for any kind of work, novel or not. You can be doing the most basic thing, if you let it iterate long enough, it will start doing something completely stupid. It's really sad watching Gemini CLI debugging something trivial, and trying to change it "one last time" again. Fortunately, Claude is better at this, but you still need to steer it. And try extremely hard not to give it pointers to something you DON'T want it to do, especially if it's easy and in it's training set, because it will so gladly pick it up.