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

Be intentional about how AI changes your codebase

aicode.swerdlow.dev

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Be intentional about how AI changes your codebase

#91

Post by theshrike79 »

embedding-shape wrote: post #74
theshrike79 wrote: post #73

Earlier quoted context omitted.

And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…

"Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.

Linters can be set check for cyclomatic complexity, using old/inefficient styles of programming (go fix ftw) etc. Formatting is just an easy and clear example that everyone should understand.

Re: Be intentional about how AI changes your codebase

#92

Post by theshrike79 »

deadbabe wrote: post #76
theshrike79 wrote: post #73

Earlier quoted context omitted.

And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…

Amateurs are the one who argue about syntax. Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.

You start to care about standard syntactic rules and enforced naming conventions when you're the one waking up 4 in the morning on a Saturday to an urgent production issue and you need to fix someone else's code that's written in a completely incoherent style.

It "expresses what it intends to do" prefectly well - for the original author. Nobody else can decipher it without spending significant amounts of memory cycles.

Jack Kerouac is "quality writing" as is the Finnish national epic Kalevala.

But neither are the kind you want to read in a hurry when you need to understand something.

I want the code at work to be boring, standard and easy to understand. I can get excited by fancy expressive tricks on my own time.

Re: Be intentional about how AI changes your codebase

#93

Post by vinnymac »

xiaolu627 wrote: post #43

What changed for me isn’t that AI writes bad code by default, but that it lowers the friction to adding code faster than the team can properly absorb it. The dangerous part is not obvious bugs, it’s subtle erosion of consistency.

Well said. I have to review PRs of non-software developers nowadays.

The “what is this trying to do?” has never been harder to answer than before. It creates scenarios where 99% is correct, but the most important area is subtly broken. I prefer it to be human, where 60-80% will be correct, and the problematic areas begin to smell more and more gradually.

In my experience LLMs, at times, may hide the truth from you in a haystack made of needles.

Re: Be intentional about how AI changes your codebase

#94

Post by brabel »

benswerd wrote: post #50
abcde666777 wrote: post #46

Earlier quoted context omitted.

I don't think it will go away, I think there will remain a niche for code where we care about precision. Maybe that niche will get smaller over time, but I think it will be a hold out for quite a while. A loose analogy I've found myself using of late is comparing it to bespoke vs off the shelf suits. For instance, two things I'm currently working on: - A reasonably complicated indie game project I've been doing solo…

I write systems rust on the cutting edge all day. My work is building instant MicroVM sandboxes. I was shocked recently when it helped me diagnose a musl compile issue, fork a sys package, and rebuild large parts of it in 2 hours. Would've taken me atleast 2 weeks to do it without AI. Don't want to reveal the specific task, but it was a far out of training data problem and it was able to help me take what would've no…

Yeah a lot of us were at the point the other guy is now and thinking that writing code by hand is still an acceptable way to go. It just isn’t anymore unless you can justify spending 5 times more time in a task just because you have some principle that code needs to be written by hand. And the funny thing is that the more complex the code base, it actually becomes the more appropriate to only touch it with AI since AI can keep a lot more concepts in its mind than us human with our poultry 7 or so. I think only a few die hard programmers will keep thinking that in a year from now.

Re: Be intentional about how AI changes your codebase

#95

Post by abcde666777 »

brabel wrote: post #94
benswerd wrote: post #50

Earlier quoted context omitted.

I write systems rust on the cutting edge all day. My work is building instant MicroVM sandboxes. I was shocked recently when it helped me diagnose a musl compile issue, fork a sys package, and rebuild large parts of it in 2 hours. Would've taken me atleast 2 weeks to do it without AI. Don't want to reveal the specific task, but it was a far out of training data problem and it was able to help me take what would've no…

Yeah a lot of us were at the point the other guy is now and thinking that writing code by hand is still an acceptable way to go. It just isn’t anymore unless you can justify spending 5 times more time in a task just because you have some principle that code needs to be written by hand. And the funny thing is that the more complex the code base, it actually becomes the more appropriate to only touch it with AI since A…

That you even describe it as holding concepts in its mind sounds like confusion to me.

As does the reductionist idea that human thinking is something crude in comparison.

Re: Be intentional about how AI changes your codebase

#96

Post by dec0dedab0de »

theshrike79 wrote: post #87
dec0dedab0de wrote: post #75

Earlier quoted context omitted.

interesting that they don’t mention doctest which has been a python built-in for quite a while. It allows you to write simple unit tests directly in your doc strings, by essentially copying the repl output so it doubles as an example. combined with something like sphinx that is almost exactly what you’re looking for. doctest kind of sucks for anything where you need to set up state, but if you’re writing functional c…

Doctest is writing unit tests in doctstrings. That system is an unit test that checks that functions are documented in the documentation. Nothing to do with docstrings.

right but docstrings are documentation, so if your doctest is working, then at least that part of the documentation is correct.

Even without doctest, generating your documentation from docstrings is much easier to keep updated than writing your documentation somewhere else, because it is right there as you are making changes.

Re: Be intentional about how AI changes your codebase

#97

Post by mchaver »

theshrike79 wrote: post #73
embedding-shape wrote: post #72

Earlier quoted context omitted.

> then it's all just feels Would that be so bad? "Readability" sure is subjective, so it seems "code quality" is. Ask 10 programmers what quality a snippet of code is, and you'll get 10 different answers.

And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

In my 15 years of experience I have not worked at a place like this. Those are distractions. Anytime something about style has been brought up, the solution was to just enforce a linter/pre-commit process/blacklist for certain functions, etc. It can easily be automated. When those tools don't exist for particular ecosystems we made our own.

Re: Be intentional about how AI changes your codebase

#98

Post by bcjdjsndon »

earljwagner wrote: post #45

The concepts of Semantic Functions and Pragmatic Functions seem to be analogous to a Functional Core and Imperative shell (FCIS): https://testing.googleblog.com/2025/10/simplify-your-code-fu... The key insight of FCIS is that complicated logic with large dependencies leads to a large test suite that runs slowly. The solution is to isolate the complicated logic in the functional core. Test that separately from the sim…

I think it's much better put in your link. Op is too vague on what constitutes pragmatic v semantic... when what he should just say is make it pure functional because then you don't have to simulate a database in your test suite.

Re: Be intentional about how AI changes your codebase

#99

Post by datsci_est_2015 »

theshrike79 wrote: post #90
datsci_est_2015 wrote: post #85

Earlier quoted context omitted.

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. Holy strawman Batman! Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review. Here’s an example code review from this week from me to a colleague, paraphrased: “We should…

So you're fine with people using, for example, different brace styles at random? Or one person uses var everywhere, other uses definite types. One adds standard docstrings on every function and property, one never comments a single line of code. Don't you have "format on save" enabled in your editor? When you open a file, change two lines and save -> boom 500 changed lines because the previous programmer had differen…

> Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions.

…

> This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules.

I’m confused, have you switched your position on this topic over the course of this thread? Maybe I’ve misinterpreted your position entirely. If so, my bad.

Re: Be intentional about how AI changes your codebase

#100

Post by dotancohen »

theshrike79 wrote: post #90
datsci_est_2015 wrote: post #85

Earlier quoted context omitted.

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. Holy strawman Batman! Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review. Here’s an example code review from this week from me to a colleague, paraphrased: “We should…

So you're fine with people using, for example, different brace styles at random? Or one person uses var everywhere, other uses definite types. One adds standard docstrings on every function and property, one never comments a single line of code. Don't you have "format on save" enabled in your editor? When you open a file, change two lines and save -> boom 500 changed lines because the previous programmer had differen…

You're bikeshedding in a conversation about real issues.

After a certain point in your career you don't care what brace style the new dev used, even if the project has lint rules. You do care if critical errors are ignored and possibly incorrect data is returned. These two situations are in no way equivalent, no need to bikeshed the former when discussing the latter.

Post reply on HN