Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The highest quality codebase

gricha.dev

Post reply on HN
Print view View original

391–400 of 409 posts

Re: The highest quality codebase

#391

Post by pdntspa »

danielmarkbruce wrote: post #303
pdntspa wrote: post #299

Earlier quoted context omitted.

I feel this too. And it seems like the very worst code always seems to come from the people that seem the smartest, otherwise. I've worked for a couple of people that are either ACM alum and/or have their own wikipedia page, multiple patents to their name and leaders in business, and beyond anyone else that I have ever worked with, their code has been the worst. Which is part of what I find so motivating with AI. It…

did you ever consider their code was good and it's you that is the problem?

I did, and that is very much not the case here.

I don't know how a "good" programmer opens the same gig+ file for writing in multiple threads (dozens sometimes) without any kind of concurrency management.

A "good" programmer doesn't give you a 2000+-line python script where every variable has no more than two characters in its name, with 0 comments or explanatory info.

A "good" programmer doesn't write a cluster that checks an "OK" REST endpoint on a regular interval, and then have that same cluster freak the fuck out and check 10-100x as often if that "OK" does not arrive exactly as it should.

Re: The highest quality codebase

#392

Post by elzbardico »

bongodongobob wrote: post #354
elzbardico wrote: post #304

Earlier quoted context omitted.

Because there are not a lot of high quality examples of code edition on the training corpora other than maybe version control diffs. Because editing/removing code requires that the model output tokens for tools calls to be intercepted by the coding agent. Responses like the example below are not emergent behavior, they REQUIRE fine-tuning. Period. I need to fix this null pointer issue in the auth module. {"id": "call…

I'm not disagreeing with any of this. Feels kind of hostile.

I clicked reply on the wrong level. And even then, I assure you I am not being hostile. English is a second language to me.

Re: The highest quality codebase

#393

Post by PaulDavisThe1st »

snovv_crash wrote: post #334
PaulDavisThe1st wrote: post #328

Earlier quoted context omitted.

> Coding is just a formal specification If you really believe this, I'd never want to hire you. I mean, it's not wrong, it's just ... well, it's not even wrong.

I'd still hire them, in fact I see that level of understanding as a green flag. Your response and depth of reasoning about why you wouldn't hire them is a red flag though. Not for a manager role and certainly not as an IC.

I provided zero depth of reasoning.

Coding is as much a method of investigating and learning about a problem as it is any sort of specification. It is as much play as it is description. Somebody who views code as nothing more than a formal specification that tells a computer what to do is inhibiting their ability to play imaginatively with the problem space, and in the work that I do, that is absolutely critical.

Re: The highest quality codebase

#394

Post by pdntspa »

traceroute66 wrote: post #380
pdntspa wrote: post #43

Earlier quoted context omitted.

That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the…

I don't follow. In the same breath (same paragraph) you state two polar opposites about working with AI: - I am phenomenally productive - "as long as I occasionally have it stop" and "it tends to forget a lot of rules like DRY" I don't see how you can claim to be "phenomenally productive" when working with a tool you have to babysit because it forgets your instructions the whole time. If it was the "junior dev" you a…

You don't have to follow. I'm still punching way above my weight. Not sure why both things can't be true at once.

Re: The highest quality codebase

#395

Post by loloquwowndueo »

theshrike79 wrote: post #250
loloquwowndueo wrote: post #148

Earlier quoted context omitted.

“Sorry, the autogenerated api documentation was wrong because the ai hallucinated the docstring”

You can't read? Please don't say you commit AI-generated stuff without checking it first?

I don’t commit ai-generated stuff. Do you?

Re: The highest quality codebase

#396

Post by keeda »

skydhash wrote: post #358
keeda wrote: post #319

Earlier quoted context omitted.

I think you would be surprised by how much these AIs can "fill in the blanks" based on the surrounding code and high-level context! Here is an example I posted a few months ago (which is coincidentally, related to the reply I just gave the sibling comment): https://news.ycombinator.com/item?id=44892576 Look at the length of my prompt and the length of the code. And that's not even including the tests I had it generat…

I’m not surprised. It would be like being suprised by the favt that computers can generate a human portrait (which has been been a thing before LLMs), but people are still using 3d software because while it takes more time, they have more control over the final result.

We still have complete control over the code, because after the AI generates it, it's right there to tweak as we want!

But the point is, there were no assumptions or tooling or bad designs that had to be fought. Just an informal, high-level prompt that generated the exact code I wanted in a fraction of the time. At least to me that was pretty surprising -- even if it'd become routine for a while by then -- because I'd expect that level of wavelength-match between colleagues who had been working on the same team for a while.

Re: The highest quality codebase

#397

Post by keeda »

skydhash wrote: post #374
keeda wrote: post #317

Earlier quoted context omitted.

> My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. I'm not the person you originally replied to, so my take is different, which explains your confusion :-) However I do increasingly get the niggling sense I'm reviewing code out of habit rather than any specific benefit bec…

What people are wary of is not solving the problem in the first pass. They are wary of technical debt and unmaintainable code. The cost of change can be enormous. Software engineering is mostly about solving current problems and laying the foundation to adapt for future ones at the same time. Your approach's only focus is current problems which is pretty much the same as people that copypaste from StackOverflow witho…

Technical debt and understanding is exactly why I still review the code.

But as I said, it's getting rare that I need to change anything the AI generates. That's partly because I decompose the problem into small, self-contained tasks that are largely orthogonal and easily tested -- mostly a functional programming style. There's very little that can go wrong because there is little ambiguity in the requirements, which is why a 3 line prompt can reliably turn into dozens of lines of working, tested code.

The main code I deal with manually is the glue that composes these units to solve the larger computer vision problem. Ironically, THAT is where the tech debt is, primarily because I'm experimenting with combinations of dozens of different techniques and tweaks to see what works best. If I knew what was going to work, I'd just prompt the AI to write it for me! ;-)

Re: The highest quality codebase

#398

Post by danielmarkbruce »

pdntspa wrote: post #391
danielmarkbruce wrote: post #303

Earlier quoted context omitted.

did you ever consider their code was good and it's you that is the problem?

I did, and that is very much not the case here. I don't know how a "good" programmer opens the same gig+ file for writing in multiple threads (dozens sometimes) without any kind of concurrency management. A "good" programmer doesn't give you a 2000+-line python script where every variable has no more than two characters in its name, with 0 comments or explanatory info. A "good" programmer doesn't write a cluster that…

I'll take a guess - you've never spent a minute at a company that is considered world class as far a software engineering goes. Am I right?

Re: The highest quality codebase

#399

Post by lazarus01 »

xnorswap wrote: post #18

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

>> But right now, the best way to help an LLM is have a deep understanding of the problem domain yourself, and just leverage it to do the grunt-work that you'd find boring.

This is exactly how I use it. I prefer Gemini 3 personally.

I try to learn as much as I can about different architectures, usually by reading books or other implementations and coding first principals to build a mental model. I apply the architecture to the problem and the AI fills in the gaps. I try my best to focus and cover those gaps.

The reason I think it is inconsistent in nailing a variety of tasks is the recipe for training LLMs, which is pre-training + RL. The RL environment sends a training signal to update all the weights in its trajectory for the successful response. Karpathy calls it “sucking supervision through a straw”. This breaks other parts of the model.

Re: The highest quality codebase

#400

Post by charleshn »

xnorswap wrote: post #18

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

It's fundamentally because of verifier's law [0].

Current AI, and in particular RL-based, is already or will soon achieve super human performance on problems that can be - quickly - verified and measured.

So maths, algorithms, etc and well defined bugs fall into that category.

However architectural decision, design, long-term planning where there is little data, no model allowing synthetic data generation, and long iteration cycles are not so much amenable to it.

[0] https://www.jasonwei.net/blog/asymmetry-of-verification-and-...

Post reply on HN