Top
Best
New

Posted by i5heu 3 hours ago

How to effectively write quality code with AI(heidenstedt.org)
101 points | 77 comments
joriJordan 4 minutes ago|
My tricks:

Define data structures manually, ask AI to implement specific state changes. So JSON, C .h or other source files of func sigs and put prompts in there. Never tried the Agents.md monolithic definition file approach

Also I demand it stick to a limited set of processing patterns. Usually dynamic, recursive programming techniques and functions. They just make the most sense to my head and using one style I can spot check faster.

I also demand it avoid making up abstractions and stick to mathematical semantics. Unique namespaces are not relevant to software in the AI era. It's all about using unique vectors as keys to values.

Stick to one behavior or type/object definition per file.

Only allow dependencies that are designed as libraries to begin with. There is a ton of documentation to implement a Vulkan pipeline so just do that. Don't import an entire engine like libgodot.

And for my own agent framework I added observation of my local system telemetry via common Linux files and commands. This data feeds back in to be used to generate right-sized sched_ext schedules and leverage bpf for event driven responses.

Am currently experimenting with generation of small models of my own data. A single path of images for example not the entire Pictures directory. Each small model is spun akin to a Docker container.

LLMs are monolithic (massive) zip files of the entire web. No one really asking for that. And anyone who needs it already has access to the web itself

OptionOfT 2 hours ago||
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.

agumonkey 1 hour ago||
I second this. This* is the matter against which we form understanding. This here is the work at hand, our own notes, discussions we have with people, the silent walk where our brain kinda process errors and ideas .. it's always been like this since i was a kid, playing with construction toys. I never ever wanted somebody to play while I wait to evaluate if it fits my desires. Desires that often come from playing.

Outsourcing this to an LLM is similar to an airplane stall .. I just dip mentally. The stress goes away too, since I assume the LLM will get rid of the "problem" but I have no more incentives to think, create, solve anything.

Still blows my mind how different people approach some fields. I see people at work who are drooling about being able to have code made for them .. but I'm not in that group.

doug_durham 1 hour ago|||
I'll push it back against this a little bit. I find any type of deliberative thinking to be a forcing function. I've recently been experimenting with writing very detailed specifications and prompts for an LLM to process. I find that as I go through the details, thoughts will occur to me. Things I hadn't thought about in the design will come to me. This is very much the same phenomenon when I was writing the code by hand. I don't think this is a binary either or. There are many ways to have a forcing function.
hed 1 hour ago|||
I think it's analogous to writing and refining an outline for a paper. If you keep going, you eventually end up at an outline where you can concatenate what are basically sentences together to form paragraphs. This is sort of where you are now, if you spec well you'll get decent results.
agumonkey 1 hour ago|||
I agree, I felt this a bit. The LLM can be a modeling peer in a way. But the phase where it goes to validate / implement is also key to my brain. I need to feel the details.
CTDOCodebases 36 minutes ago||||
I wonder over the long term how programmers are going to maintain the proficiency to read and edit the code that the LLM produces.
agumonkey 32 minutes ago||
Personally I planned to allocate weekly challenges to stay sharp.
Akranazon 1 hour ago|||
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.
gtowey 1 hour ago|||
Maybe.

But it's also likely that these tools will produce mountains of unmaintainable code and people will get buried by the technical debt. It kind of strikes me as similar to the hubris of calling the Titanic "unsinkable." It's an untested claim with potentially disastrous consequences.

rapind 1 hour ago||
> 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 YOLO to me. I guess you can somewhat compensate with reams of tests though. (which begs the question, is the dynamic language still saving you time?)

agumonkey 1 hour ago|||
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.
acedTrex 1 hour ago||
Yep, its a rather depressing realization isnt it. Oh well, life moves on i suppose.

I think we realistically have a few years of runway left though. Adoption is always slow outside of the far right of the bell curve.

agumonkey 31 minutes ago||
i'm sorry if I pulled everybody down .. but it's been many months since gemini and claude became solid tools, and regularly i have this strong gut feeling. i tried reevaluating my perception of my work, goals, value .. but i keep going back to nope.
rapind 1 hour ago|||
I still do this, but when I'm reviewing what's been written and / or testing what's been built.

How I see it is we've reverted back to a heavier spec type approach, however the turn around time is so fast with agents that it still can feel very iterative simply because the cost of bailing on an approach is so minimal. I treat the spec (and tests when applicable) as the real work now. I front load as much as I can into the spec, but I also iterate constantly. I often completely bail on a feature or the overall approach to a feature as I discover (with the agent) that I'm just not happy with the gotchas that come to light.

AI agents to me are a tool. An accelerator. I think there are people who've figured out a more vibey approach that works for them, but for now at least, my approach is to review and think about everything we're producing, which forms my thoughts as we go.

jeppester 1 hour ago|||
That's also how I feel.

I think you have every right to doubt those telling us that they run 5 agents to generate a new SAAS-product while they are sipping latté in a bar. To work like that I believe you'll have to let go of really digging into the code, which in my experience is needed if want good quality.

Yet I think coding agents can be quite a useful help for some of the trivial, but time consuming chores.

For instance I find them quite good at writing tests. I still have to tweak the tests and make sure that they do as they say, but overall the process is faster IMO.

They are also quite good at brute-forcing some issue with a certain configuration in a dark corner of your android manifest. Just know that they WILL find a solution even if there is none, so keep them on a leash!

Today I used Claude for bringing a project I abandoned 5 years ago up to speed. It's still at work in progress, but the task seemed insurmountable (in my limited spare time) without AI, now it feels like I'm half-way there in 2-3 hours.

frankc 1 hour ago|||
I think we really need to have a serious think of what is "good quality" in the age of coding agents. A lot of the effort we put into maintaining quality has to do with maintainability, readability etc. But is it relevant if the code isn't for humans? What is good for a human is not what is good for an AI necessarily (not to say there is no overlap). I think there are clearly measurable things we can agree still apply around bugs, security etc, but I think there are also going to be some things we need to just let go of.
skydhash 51 minutes ago||
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.
tjr 47 minutes ago||
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 HTML.

bornfreddy 9 minutes ago||
So like we went from assembler to higher level programming languages, we will now move to specifications for LLMs? Interesting thought... Maybe, once the "compilers" get good enough, but for mission critical systems they are not nearly good enough yet.
tjr 2 minutes ago||
Right. I work in aerospace software, and I do not know if this option would ever be on the table. It certainly isn't now.

So I think this question needs to be asked in the context of particular projects, not as an industry-wide yes or no answer. Does your particular project still need humans involved at the code level? Even just for review? If so, then you probably ought to retain human-oriented software design and coding techniques. If not, then, whatever. Doesn't matter. Aim for whatever efficiency metric you like.

palmotea 39 minutes ago|||
> I think you have every right to doubt those telling us that they run 5 agents to generate a new SAAS-product while they are sipping latté in a bar. To work like that I believe you'll have to let go of really digging into the code, which in my experience is needed if want good quality.

Also we live in a capitalist society. The boss will soon ask: "Why the fuck am I paying you to sip a latte in a bar? While am machine does your work? Use all your time to make money for me, or you're fired."

AI just means more output will be expected of you, and they'll keep pushing you to work as hard as you can.

raw_anon_1111 7 minutes ago|||
In 1987 when I first started coding, I would either write my first attempt in BASIC and see it was too slow and rewrite parts in assembly or I would know that I had to write what I wanted from the get go in assembly because the functionality wasn’t exposed at all in BASIC (using the second 64K of memory or using double hires graphics).

This past week, I spent three days modifying a web solution written by someone else using Codex - without looking at the code as someone who hasn’t done front in development in a decade - I verified the functionality.

More relevantly but related, I spent a couple of hours thinking through an architecture - cloud + an Amazon managed service + infrastructure as code + actual coding, diagramming it, labeling it , and thinking about the breakdown and phases to get it done. I put all of the requirements - that I would have done anyway - into a markdown file and told Claude and Codex to mark off items as I tested each item and summarize what it did.

Looking at the amount of work, between modifying the web front end and the new work, it would have taken two weeks with another developer helping me before AI based coding. It took me three or four days by myself.

The real kicker though is while it worked as expected for a couple of hundred documents, it fell completely to its knees when I threw 20x documents into the system. Before LLMs, this would have made me look completely incompetent telling the customer I now wasted two weeks worth of time and 2 other resources.

Now, I just went back to the literal drawing board, rearchitected it, did all of the things that the managed services abstracted away with a few tweaks, created a new mark down file and was done in a day. That rework would have taken me a week by itself. I knew the theory behind what the managed service was doing. But in practice I had never done it.

It’s been over a decade where I was responsable for a delivery that I could do by myself without delegating to other people or that was simple enough that I wouldn’t start with a design document for my own benefit. Now within the past year, I can take on larger projects by myself without the coordination/“mythical man Month” overhead.

I can also in a moment of exasperation say to Codex “what you did was over complicated stupid mess, rethink your implementation from first principles” without getting reported to HR.

There is also a lot of nice to have gold plating that I will do now knowing that it will be a lot faster

wasmainiac 1 hour ago|||
I also second this. I find that I write better by hand, although I work on niche applications it’s not really standard crud or react apps. I use LLMs in the same way i used to used stack overflow, if I go much farther to automate my work than that I spend more time on cleanup compared to if I just write code myself.

Sometimes the AI does weird stuff too. I wrote a texture projection for a nonstandard geometric primitive, the projection used some math that was valid only for local regions… long story. Claude kept on wanting to rewrite the function to what it thought was correct (it was not) even when I directed to non related tasks. Super annoying. I ended up wrapping the function in comments telling it to f#=% off before it would leave it alone.

discreteevent 2 hours ago|||
Exactly. 30 years ago a mathematician I knew said to me: "The one thing that you can say for programming is that it forces you to be precise."

We vibe around a lot in our heads and that's great. But it's really refreshing, every so often, to be where the rubber meets the road.

the_duke 1 hour ago|||
That's because many developers are used to working like this.

With AI, the correct approach is to think more like a software architect.

Learning to plan things out in your head upfront without to figure things out while coding requires a mindset shift, but is important to work effectively with the new tools.

To some this comes naturally, for others it is very hard.

skydhash 1 hour ago||
I think what GP is referring too are technical semantics and accidental complexity. You can’t plan for those.

The same kind of planning you’re describing can and do happen sans LLM, usually on the sofa, or in front of a whiteboard. Or by reading some research materials. No good programmer rushes to coding without a clear objective.

But the map is not the territory. A lot of questions surface during coding. LLMs will guess and the result may be correct according to the plan, but technically poor, unreliable, or downright insecure.

chasd00 1 hour ago|||
Using AI or writing your own code isn't an xor thing. You can still write the code but have a coding assistant or something an alt/cmd-tab away. I enjoy writing code, it relaxes me so that's what I do but when I need to look something up or i'm not clear on the syntax for some particular operation instead of tabbing to a browser and google.com I tab to the agent and ask it to take a look. For me, this is especially helpful for CSS and UI because I really suck at and dislike that part of development.

I also use these things to just plan out an approach. You can use plan mode for yourself to get an idea of the steps required and then ask the agent to write it to a file. Pull up the file and then go do it yourself.

positron26 11 minutes ago|||
Are there still people under the impression that the correct way to use Stack Overflow all these years was to copy & paste without analyzing what the code did and making it fit for purpose?

If I have to say, we're just waiting for the AI concern caucus to get tired of performing for each other and justifying each other's inaction in other facets of their lives.

vunderba 1 hour ago|||
Sounds like the coders equivalent of the Whorfian hypothesis.
shinryuu 2 hours ago|||
I couldn't agree more. It's often when you are in the depth of the details that I make important decisions on how to engineer the continuation.
jofla_net 1 hour ago||
Yes, I look at this in a similar vein to the (Eval <--> Appply) Cycle in SICP textbook, as a (Design <--> Implement) cycle.
PeterStuer 1 hour ago|||
Any sufficiently detailed specification converges on code.
tayo42 2 hours ago|||
I was just thinking this the other day after I did a coding screen and didn't do well. I know the script for the interviewee is your not suppsed to write any code until you talk through the whole thing, but I think i woukd have done better if I could have just wrote a bunch of throw away code to iterate on.
throwaway613746 1 hour ago||
[dead]
whynotminot 1 hour ago||
The real value that AI provides is the speed at which it works, and its almost human-like ability to “get it” and reasonably handle ambiguity. Almost like tasking a fellow engineer. That’s the value.

By the time you do everything outlined here you’ve basically recreated waterfall and lost all speed advantage. Might as well write the code yourself and just use AI as first-pass peer review on the code you’ve written.

A lot of the things the writer points out also feel like safeguards against the pitfalls of older models.

I do agree with their 12th point. The smaller your task the easier to verify that the model hasn’t lost the plot. It’s better to go fast with smaller updates that can be validated, and the combination of those small updates gives you your final result. That is still agile without going full “specifications document” waterfall.

adriand 1 hour ago|
It’s a solid post overall and even for people with a lot of experience there’s some good ideas in here. “Identify and mark functions that have a high security risk, such as authentication, authorization” is one such good idea - I take more time when the code is in these areas but an explicit marking system is a great suggestion. In addition to immediate review benefits, it means that future updates will have that context.

“Break things down” is something most of us do instinctively now but it’s something I see less experienced people fail at all the time.

blauditore 20 minutes ago||
I can't help but keep finding it ridiculous how everyone now discovers basic best practices (linting, documentation, small incremental changes) that have been known for ages. It's not needed because of AI, you should have been doing it like this before as well.
rektlessness 5 minutes ago||
All this boils down to is that AI wins when it amplifies engineers, not replaces them. And the best code still comes from devs who ultrathink.
jweir 43 minutes ago||
Remember having to write detailed specs before coding? Then folks realized it was faster and easier to skip the specs and write the code? So now are we back to where we were?

One of the problems with writing detailed specs is it means you understand the problem, but often the problem is not understand - but you learn to understand it through coding and testing.

So where are we now?

bitwize 26 minutes ago|
Astronaut 1, AI-assisted developers: You mean, it's critical to plan and spec out what you want to write before you start in on code?

Astronaut 2, Tim Bryce: Always has been...

bornfreddy 21 minutes ago||
I found an easier way that Works For Me (TM). I describe the problem to LLM and ask it to solve it step by step, but strictly in the Ask mode, not Agent. Then I copy or even type the linws to the code. If I wouldn't write the line myself, it doesn't go in, and I iterate some more.

I do allow it to write the tests (lots of typing there), but I break them manually to see how they fail. And I do think about what the tests should cover before asking LLM to tell me (it does come up with some great ideas, but it also doesn't cover all the aspects I find important).

Great tool, but it is very easy to be led astray if you are not careful.

kbaker 10 minutes ago||
The GSD tool (get-shit-done) automates a very similar process to this, and has been mind-blowing for larger projects and refactors.

https://github.com/glittercowboy/get-shit-done

You still need to know the hard parts: precisely what you want to build, all domain/business knowledge questions solved, but this tool automates the rest of the coding and documentation and testing.

It's going to be a wild future for software development...

egrtah 1 hour ago||
Too bad that software developers are carrying water for those who hate them and mock them for being obsolete in 6-12 months, while they are eating caviar (probably evading sanctions) and clink the champagne glasses in Davos:

https://xcancel.com/hamptonism/status/2019434933178306971

And all that after stealing everyone's output.

atomic128 1 hour ago|
Underground Resistance Aims To Sabotage AI With Poisoned Data

https://news.ycombinator.com/item?id=46827777

red75prime 26 minutes ago||
Textile workers sabotage mechanical looms. History repeats itself.
atomic128 8 minutes ago||
"Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them." (Frank Herbert, Dune)
blmarket 1 hour ago|
Some pattern I found from my hobby project.

1. Keep things small and review everything AI written, or 2. Keep things bloated and let AI do whatever it wants within the designated interface.

Initially I drew this line for API service / UI components, but it later expanded to other domains. e.g. For my hobby rust project I try to keep "trait"s to be single responsible, never overlap, easy to understand etc etc. but I never look at AI generated "impl"s as long as it passes some sensible tests and conforming the traits.

rustyhancock 1 hour ago||
I'm finding Rust is perfect for me with LLMs.

I find rust generally easier to reason about, but can't stand writing it.

The compiler works well with LLMs plenty of good tooling and LSPs.

If I'm happy with the shape of the code and I usually write the function signatures/ Module APIs. And the compiler is happy with it compiling. Usually the errors if any are logical ones I should catch in reviews.

So I focus on function, compiler focuses on correctness and LLM just does the actual writing.

bwestergard 1 hour ago||
Do you think Rust will end up getting a boost from LLM adoption?
rustyhancock 1 hour ago||
It definitely has for me! I just replied to the parent explaining why.

Tl;Dr I don't mind reading rust I hate writing it and the compiler meets me in the middle.

gck1 19 minutes ago||
Same here. I had to do a lot of being in the loop with Python, but with rust - compiler gives Claude all the information it may need and then it figures things out without me.

Writing rust scares me, but I can read it just fine. I've come up with super masochistic linting rules that claude isn't allowed to change and that has improved things quite a bit.

I wish there was a mature framework for frontend that can be configured to be as strict as rust.

More comments...