Live data from Hacker News

How to effectively write quality code with AI

heidenstedt.org

131–140 of 321 posts

Re: How to effectively write quality code with AI

#131
post #52

Earlier quoted context omitted.

You can’t drop anything as long as a programmer is expected to edit the source code directly. Good luck investigating a bug when the code is unclear semantically, or updating a piece correctly when you’re not really sure it’s the only instance.

I think that's the question. Is a programmer expected to ever touch the source code? Or will AI -- and AI alone -- update the code that it generated? Not entirely unlike other code generation mechanisms, such as tools for generating HTML based on a graphical design. A human could edit that, but it may not have been the intent. The intent was that, if you want a change, go back to the GUI editor and regenerate the HTM…

> Not entirely unlike other code generation mechanisms, such as tools for generating HTML based on a graphical design. A human could edit that, but it may not have been the intent. The intent was that, if you want a change, go back to the GUI editor and regenerate the HTML.

We largely moved back away from "work in a graphic tool then spit out HTML from it" because it wasn't robust for the level of change/iteration pace, this wasn't exactly my domain but IIRC there were especially a lot of problems around "small-looking changes are now surprisingly big changes in the generated output that have a large blast radius in terms of the other things (like interactivity) we've added in."

Any time you do a refactor that changes contract boundaries between functions/objects/models/whatever, and you have to update the tests to reflect this, you have a big risk of your new tests not covering exactly the same set of component interactions that your old tests did. LLM's don't change this. They can iterate until the tests are green, but certain changes will require changing the tests, and now "iterating until the tests are green" could be resolved by changing the tests in a way that subtly breaks surprising user-facing things.

The value of good design in software is having boundaries aligned with future desires (obviously this is never perfect foresight) to minimize that risk. And that's the scary thing to myself about not even reading the code.

Re: How to effectively write quality code with AI

#132

The post touches very briefly on linting in 7. For me, setting up a large number of static code analysis checks has had the highest impact on code quality. My hierarchy of static analysis looks like this (hierarchy below is Typescript focused but in principle translatable to other languages): 1. Typesafe compiler (tsc) 2. Basic lint rules (eslint) 3. Cyclomatic complexity rules (eslint, sonarjs) 4. Max line length en…

These kinda things aren’t really the issues I run into. Lack of clarity of thought, overly verbose code, needlessly defensive programming - the stuff that really rots a codebase. Honestly some of the above rules you have I’d want the LLM to ignore at the times if we’re going for maximum maintainability.

Re: How to effectively write quality code with AI

#133

Earlier quoted context omitted.

Everything you have said here is completely true, except for "not in that group": the cost-benefit analysis clearly favors letting these tools rip, even despite the drawbacks.

Oh I'm well aware of this. I admitted defeat in a way.. I can't compete. I'm just at loss, and unless LLM stall and break for some reason (ai bubble, enshittification..) I don't see a future for me in "software" in a few years.

So why havent you been fired already?

.......

Re: How to effectively write quality code with AI

#134
post #85
post #47

Earlier quoted context omitted.

> But it's also likely that these tools will produce mountains of unmaintainable code and people will get buried by the technical debt. It's not just likely, but it's guaranteed to happen if you're not keeping an eye on it. So much so, that it's really reinforced my existing prejudice towards typed and compiled languages to reduce some of the checking you need to do. Using an agent with a dynamic language feels very…

Tests make me faster. Dynamic or not feels irrelevant when I consider how much slower I’d be without the fast feedback loop of tests.

You can (and probably should) still do tests, but there's an entire class of errors you know can't happen, so you need far less tests, focusing only on business logic for the most part.

Re: How to effectively write quality code with AI

#135

Earlier quoted context omitted.

Everything you have said here is completely true, except for "not in that group": the cost-benefit analysis clearly favors letting these tools rip, even despite the drawbacks.

Oh I'm well aware of this. I admitted defeat in a way.. I can't compete. I'm just at loss, and unless LLM stall and break for some reason (ai bubble, enshittification..) I don't see a future for me in "software" in a few years.

Yup. The majority of this website is going to find out they were grossly overpaid for a long time.

Re: How to effectively write quality code with AI

#136

I wonder at the end of this if it's the still worth the risk? A lot of how I form my thoughts is driven by writing code, and seeing it on screen, running into its limitations. Maybe it's the kind of work I'm doing, or maybe I just suck, but the code to me is a forcing mechanism into ironing out the details, and I don't get that when I'm writing a specification.

I dunno. On the one hand, I keep hearing anecdata, including hackernews comments, friends, and coworkers, suggesting that AI-assisted coding is a literal game changer in terms of productivity, and if you call yourself a professional you'd better damn well lock the fuck in and learn the tools. At the extreme end this takes the form of, you're not a real engineer unless you use AI because real engineering is about using the optimal means to solve problems within time, scale, and budget constraints, and writing code by hand is now objectively suboptimal.

On the other hand, every time the matter is seriously empirically studied, it turns out that overall:

* productivity gains are very modest, if not negative

* there are considerable drawbacks, including most notably the brainrot effect

Furthermore, AI spend is NOT delivering the promised returns to the extent that we are now seeing reversals in the fortunes of AI stocks, up to and including freakin' NVIDIA, as customers cool on what's being offered.

So I'm supposed to be an empiricist about this, and yet I'm supposed to switch on the word of a "cool story bro" about how some guy built an app or added a feature the other day that he totally swears would have taken him weeks otherwise?

I'm like you. I use code as a part of my thought process for how to solve a problem. It's a notation for thought, much like mathematical or musical notation, not just an end product. "Programs must be written for people to read, and only incidentally for machines to execute." I've actually come to love documenting what I intend to do as I do it, esp. in the form of literate programming. It's like context engineering the intelligence I've got upstairs. Helps the old ADHD brain stay locked in on what needs to be done and why. Org-mode has been extremely helpful in general for collecting my scatterbrained thoughts. But when I want to experiment or prove out a new technique, I lean on working directly with code an awful lot.

Re: How to effectively write quality code with AI

#137

Earlier quoted context omitted.

Everything you have said here is completely true, except for "not in that group": the cost-benefit analysis clearly favors letting these tools rip, even despite the drawbacks.

Oh I'm well aware of this. I admitted defeat in a way.. I can't compete. I'm just at loss, and unless LLM stall and break for some reason (ai bubble, enshittification..) I don't see a future for me in "software" in a few years.

The future is either a language model trained on AI code bloats and the ways to optimize the bloat away

OR,

something like Mercor, currently getting paid really well by Meta, OpenAI, Anthropic and Gemini to pay very smart humans really well to proof language model outputs.

Re: How to effectively write quality code with AI

#138
post #57

Every engineering org should be pleading devs to not let AI write tests. They're awful and sometimes they literally don't even assert the code that was generated and instead assert the code in tests.

Every engineering org should be pleading devs to not let AI write code, period. They continue to routinely get stuff wrong and can't be trusted any further than you can throw them.

Re: How to effectively write quality code with AI

#139

The post touches very briefly on linting in 7. For me, setting up a large number of static code analysis checks has had the highest impact on code quality. My hierarchy of static analysis looks like this (hierarchy below is Typescript focused but in principle translatable to other languages): 1. Typesafe compiler (tsc) 2. Basic lint rules (eslint) 3. Cyclomatic complexity rules (eslint, sonarjs) 4. Max line length en…

this is close to what i've landed on too. the pre-commit hook is non-negotiable. i've had Claude Code report "all checks pass" when there were 14 failing eslint rules. beyond the static analysis though, i keep hitting a harder problem: code that passes every lint rule, compiles clean, and greens the test suite but implements a subtly wrong interpretation of the spec. like an API handler that returns 200 with an empty array instead of 404, technically valid but semantically wrong. evaluating behavioural correctness against intent, not just syntax or type safety, is the gap nobody's really cracked yet. property-based testing helps but it still requires you to formalize the invariants upfront, which is often the hard part.

Re: How to effectively write quality code with AI

#140

That sounds like the advice of someone who doesn't actually write high-quality code. Perhaps a better title would be "how to get something better than pure slop when letting a chatbot code for you" - and then it's not bad advice I suppose. I would still avoid such code if I can help it at all.

Man, you are really missing out of the biggest revolution of my life. This is the opinion of someone who has not tried to use Claude Code, in a brand new project with full permissions enabled, and with a model from the last 3 months.

People have been saying "the models from (recent timeframe) are so much better than the old ones, they solve all the problems" for years now. Since GPT-4 if not earlier. Every single time, those goalposts have shifted as soon as the next model came out. With such an abysmal track record, it's not reasonable to expect people to believe that this time the tool actually has become good and that it's not just hype.
Post reply on HN