[HN Gopher] How to effectively write quality code with AI
___________________________________________________________________
How to effectively write quality code with AI
Author : i5heu
Score : 110 points
Date : 2026-02-06 18:49 UTC (4 hours ago)
(HTM) web link (heidenstedt.org)
(TXT) w3m dump (heidenstedt.org)
| OptionOfT wrote:
| 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.
| discreteevent wrote:
| 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.
| shinryuu wrote:
| 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 wrote:
| Yes, I look at this in a similar vein to the (Eval <-->
| Appply) Cycle in SICP textbook, as a (Design <--> Implement)
| cycle.
| tayo42 wrote:
| 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.
| jeppester wrote:
| 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 latte 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 latte 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.
| agumonkey wrote:
| 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.
| Akranazon wrote:
| 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.
| agumonkey wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gtowey wrote:
| 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 wrote:
| > 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?)
| zingar wrote:
| 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.
| doug_durham wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Personally I planned to allocate weekly challenges to stay
| sharp.
| blibble wrote:
| > I see people at work who are drooling about being able to
| have code made for them .. but I'm not in that group.
|
| people seem to have a inability to predict second and third
| order effects
|
| the first order effect is "I can sip a latte while the bot
| does my job for me"... well, great I suppose, while it lasts
|
| but the second order effect is: unless you're in the top 10%,
| you will now lose your job, permanently
|
| and the third order effect is the economy collapses as it is
| built on consumer spending
| vunderba wrote:
| Sounds like the coders equivalent of the Whorfian hypothesis.
| PeterStuer wrote:
| Any sufficiently detailed specification converges on code.
| chasd00 wrote:
| 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.
| wasmainiac wrote:
| 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.
| the_duke wrote:
| 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 wrote:
| 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.
| rapind wrote:
| 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.
| positron26 wrote:
| 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.
| rkafbg wrote:
| Lab-grown meat slop producer defends AI slop.
| raw_anon_1111 wrote:
| 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 a a days modifying a web solution
| written by someone else + converting it from a Terraform based
| deployment to CloudFormation 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 with code 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 an 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
| einpoklum wrote:
| 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.
| Akranazon wrote:
| 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.
| whynotminot wrote:
| This is a fading but common sentiment on hacker news.
|
| There's a lot of engineers who will refuse to wake up to the
| revolution happening in front of them.
|
| I get it. The denialism is a deeply human response.
| computerex wrote:
| It's insane! We are so far beyond gpt-3.5 and gpt-4. If
| you're not approaching Claude Code and other agentic coding
| agents with an open mind with the goal of deriving as much
| value from them as possible, you are missing out on super
| powers.
|
| On the flip side, anyone who believes you can create
| quality products with these tools without actually working
| hard is also deluded. My productivity is insane, what I can
| create in a long coding session is incredible, but I am
| working hard the whole time, reviewing outputs, devising
| GOOD integration/e2e tests to actually test the system,
| manually testing the whole time, keeping my eyes open for
| stereotypically bad model behaviors like creating
| fallbacks, deleting code to fulfill some objective.
|
| It's actually downright a pain in the ass and a very
| unpleasant experience working in this way. I remember the
| sheer flow state I used to get into when doing deep
| programming where you are so immersed in managing the
| states and modeling the system. The current way of
| programming for me doesn't seem to provide that with the
| models. So there are aspects of how I have programmed my
| whole life that I dearly miss. Hours used to fly past me
| without me being the wiser due to flow. Now that's no
| longer the case most of the times.
| falloutx wrote:
| Its only revolutionary if you think engineers were slow
| before or software was not being delivered fast enough. Its
| revolutionary for some people sure, but everyone is in a
| different situation, so one man's trash can be other man's
| treasure. Most people are treading both paths as automation
| threatens their livelihood and work they loved, also still
| not able to understand why would people pay to companies
| that are actively trying to convince your employer that
| your job is worthless.
|
| Even If I like this tech, I still dont want to support the
| companies who make it. Yet to pay a cent to these
| companies, still using the credits given to me by my
| employer.
| whynotminot wrote:
| Of course software hasn't been delivered fast enough.
| There is so so so much of the world that _still_ needs
| high quality software.
| notpachet wrote:
| > in a brand new project
|
| Must be nice. Claude and Codex are still a waste of my time
| in complex legacy codebases.
| bigfishrunning wrote:
| Brand new projects have a way of turning into legacy
| codebases
| bornfreddy wrote:
| What are you talking about? Exploring and explaining the
| legacy codebases is where they shine, in my experience.
| pletnes wrote:
| Claude code is great at figuring out legacy code! I dont get
| the <<for new systems only>> idea, myself.
| computerex wrote:
| Can you be specific? You didn't provide any constructive
| feedback, whatsoever.
| einpoklum wrote:
| The article did not provide a constructive suggestion on how
| to write quality code, either. Nor even empirical proof in
| the form of quality code written by LLMs/agents via the
| application of those principles.
| computerex wrote:
| Yes it did, it provided 12 things that the author asserts
| helps produce quality code. Feel free to address the
| content with something productive.
| dasil003 wrote:
| This take is pretty uncharitable. I write high quality code,
| but also there's a bunch of code that could be useful, but that
| I don't write because it's not worth the effort. AI unlocks a
| lot of value in that way. And if there's one thing my 25 years
| as a software engineer has taught me is that while code quality
| and especially system architecture matter a lot, being super
| precious about every line of code really does not.
|
| Don't get me wrong, I do think AI coding is pretty dangerous
| for those without the right expertise to harness it with the
| right guardrails, and I'm really worried about what it will
| mean for open source and SWE hiring, but I do think refusing to
| use AI at this point is a bit like the assembly programmer
| saying they'll never learn C.
| xandrius wrote:
| Look up luddites on Wikipedia, might be too deep to see the
| similarities though.
| egrtah wrote:
| 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 wrote:
| Underground Resistance Aims To Sabotage AI With Poisoned Data
|
| https://news.ycombinator.com/item?id=46827777
| red75prime wrote:
| Textile workers sabotage mechanical looms. History repeats
| itself.
| whynotminot wrote:
| 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 wrote:
| 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.
| raphman wrote:
| Hi i5heu. Given that you seem to use AI tools for generating
| images and audio versions of your posts, I hope it is not too
| rude to ask: how much of the post was drafted, written or edited
| with AI?
|
| The suggestions you make are all sensible but maybe a little bit
| generic and obvious. Asking ChatGPT to generate advice on
| effectively writing quality code with AI generates a lot of
| similar suggestions (albeit less well written).
|
| If this was written with help of AI, I'd personally appreciate a
| small notice above the blog post. If not, I'd suggest to augment
| the post with practical examples or anecdotal experience. At the
| moment, the target group seems to be novice programmers rather
| than the typical HN reader.
| i5heu wrote:
| Hi raphman,
|
| i have written this text by myself except like 2 or 3 sentences
| which i iterated with an LLM to nail down flow and readability.
| I would interpret that as completely written by me.
|
| > The suggestions you make are all sensible but maybe a little
| bit generic and obvious. Asking ChatGPT to generate advice on
| effectively writing quality code with AI generates a lot of
| similar suggestions (albeit less well written).
|
| Before i wrote this text, i also asked Gemini Deep Research but
| for me the results where too technical and not structural or
| high level as i describe them here. Hence the blogpost to share
| what i have found works best.
|
| > If not, I'd suggest to augment the post with practical
| examples or anecdotal experience. At the moment, the target
| group seems to be novice programmers rather than the typical HN
| reader.
|
| I have pondered the idea and also wrote a few anecdotal
| experiences but i deleted them again because i think it is hard
| to nail the right balance down and it is also highly depended
| on the project, what renders examples a bit useless.
|
| And i also kind of like the short and lean nature of it the
| last few days when i worked on the blogpost. I might will make
| a few more blogposts about that, that will expand a few points.
|
| Thank you for your feedback!
| flyisopen wrote:
| https://bcantrill.dtrace.org/2025/12/05/your-intellectual-fl...
| blmarket wrote:
| 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.
| bwestergard wrote:
| Do you think Rust will end up getting a boost from LLM
| adoption?
| rustyhancock wrote:
| 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 wrote:
| 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.
| rustyhancock wrote:
| 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.
| emsign wrote:
| Sounds like an awful lot of work and nannying just to avoid
| writing code yourself. Coding used to be fun and enjoyable
| once...
| shockwaverider wrote:
| I'm finding it to be the opposite. I used to love writing
| everything by hand but now Claude is giving me the ability to
| focus more on architecture. I like just sitting down with my
| coffee and thinking about the next part of my project, how I'd
| like it to be written and Claude just fills it in for me. It
| makes mistakes at times but it also finds a lot of mine that I
| hadn't even realized were in my code base.
| xandrius wrote:
| Yep, I get that some people love the act of literally typing
| "x = 2;" but to me coding is first and foremost problem
| solving. I have a problem (either truly mine or someone
| else's), I come up with a solution in my head and slowly
| implement it.
|
| Before I also had to code it and then make sure it had no
| issues.
|
| Now I can skip the coding and then just have something spit
| out something which I can evaluate whether I believe is a
| good implementation of my solution or not.
|
| Of course, you need the skill to know good from bad but for
| medium to senior devs, AI is incredibly useful to get rid of
| the mundane task of actually writing code, while focusing on
| problem solving with critical review of magically generated
| code.
| krashidov wrote:
| > Use strict linting and formatting rules to ensure code quality
| and consistency. This will help you and your AI to find issues
| early.
|
| I've always advocated for using a linter and consistent
| formatting. But now I'm not so sure. What's the point? If nobody
| is going to bother reading the code anymore I feel like linting
| does not matter. I think in 10 years a software application will
| be very obfuscated implementation code with thousands of very
| solidly documented test cases and, much like compiled code, how
| the underlying implementation code looks or is organized won't
| really matter
| orwin wrote:
| That's the opposite. I've never read and re-read code more than
| i do today. The new hires generate 50 more code than they use
| to, and you _have_ to check it or have compounding production
| issues (been there, done that). And the errors can now be
| anywhere, when before you more or less knew what the person
| writing code is thinking and can understand why some errors are
| made. LLMs errors could hide _anywhere_, so you have to check
| it all.
| bornfreddy wrote:
| Isn't that a losing proposition? Or do you get 50 times the
| value out of it too? In my experience the more verbose the
| code is, the less thought out it is. Lots of changes? Cool,
| now polish some more and come back when it's below 100 lines
| change, excluding tests and docs. I don't dare touch it
| before.
| gck1 wrote:
| They serve as guardrails for agents to not do stupid things.
|
| If your goal is for AI to write code that works, is
| maintainable and extensible, you have to include as many
| deterministic guardrails as possible.
| orwin wrote:
| First article about writing code with AI i can get behind 100%.
| Stuff i already do, stuff i've thought about doing, and at ideas
| i've never thought doing ("Mark code review levels" especially is
| a _great_ idea)
| jweir wrote:
| 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 wrote:
| 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...
| exitb wrote:
| We're not ,,thinking with portals" about these things enough
| yet. Typically we'd want a detailed spec beforehand, as coding
| is expensive and time consuming, thus we want to make sure
| we're coding the right thing. With AI though, coding is cheap.
| So let AI skip the spec and write the code badly. Then have it
| review the solution, build understanding, design a spec for
| better solution and have it write it again. Rinse and repeat as
| many times you need.
|
| It's also nothing new, as it's basically Joe Armstrong's
| programming method. It's just not prohibitively expensive for
| the first time in history.
| sakopov wrote:
| 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.
| johnsmith1840 wrote:
| How to write good code with AI -> put in as much effort as you
| did before on 20% more code than you used to work with.
| bornfreddy wrote:
| 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.
| blauditore wrote:
| 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.
| kbaker wrote:
| 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...
| rektlessness wrote:
| 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.
| joriJordan wrote:
| 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_
| nxobject wrote:
| In her defence, I use most of those strategies myself as well...
| InsideOutSanta wrote:
| My approach:
|
| 1. Have the LLM write code based on a clear prompt with limited
| scope 2. Look at the diff and fix everything it got wrong
|
| That's it. I don't gain a lot in velocity, maybe 10-20%, but I've
| seen the code, and I know it's good.
___________________________________________________________________
(page generated 2026-02-06 23:00 UTC)