[HN Gopher] How to effectively write quality code with AI
___________________________________________________________________
How to effectively write quality code with AI
Author : i5heu
Score : 318 points
Date : 2026-02-06 18:49 UTC (1 days 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.
| 9dev wrote:
| Then again, would anyone have guessed we'd even be
| seriously discussing this topic 10, 20, 40 years ago?
| tjr wrote:
| Maybe. This book from 1990
|
| https://mitpress.mit.edu/9780262526401/artificial-
| intelligen...
|
| envisions a future of AI assistance that looks not too
| far off from today.
| 9dev wrote:
| It's also pretty close to Steve Jobs initial vision of
| computing in the future
| (https://stevejobsarchive.com/stories/objects-of-our-
| life, 1983) but my point is that whatever it is we call
| AI now became reality so much faster than anyone really
| saw coming. Even if the pace slows down, and it didn't
| yet, things are improving so massively all the time that
| the world can't keep up changing to accommodate.
| Gud wrote:
| Not everyone works in aerospace engineering, though.
|
| I would guess that >90% of all web crud can already be
| done better by an LLM managed by a decent developer, than
| purely by the developer himself.
| Wobbles42 wrote:
| This is exactly what is happening from a levels of
| abstraction standpoint.
|
| The difference being that compilers and related tools are
| deterministic, and we can manage the outputs using
| mathematical proof of correctness.
|
| The LLM's driving this new abstraction layer are another
| beast entirely.
| majormajor wrote:
| > 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.
| tiny-automates wrote:
| i've been building agent tooling for a while and this is
| the question i keep coming back to. the actual failure mode
| isn't messy code, agents produce reasonably clean, well-
| typed output these days. it's that the code confidently
| solves a different problem than what you intended. i've had
| an agent refactor an auth flow that passed every test but
| silently dropped a token refresh check because it
| "simplified" the logic. clean code, good types, tests
| green, security hole. so for me "quality" has shifted from
| cyclomatic complexity and readability scores to "does the
| output behaviour match the specification across edge cases,
| including the ones i didn't enumerate." that's
| fundamentally an evaluation problem, not a linting problem.
| mlaretallack wrote:
| This is where I think its going, it feels that in the end
| we will end up with an "llm" language, one that is more
| suited to how an llm works and less human.
| Thanemate wrote:
| >But is it relevant if the code isn't for humans?
|
| The implications to your statement seems to me that is:
| "you'll never have to directly care about it yourself, so
| why do you care about it?". Unless you were talking about
| the codebase in a user-application relationship which in
| this case feel free to ignore the rest of my post.
|
| I don't believe that the code will become an implementation
| detail, ever. When all you do is ship an MVP to demonstrate
| what you're building then no one cares, before or after LLM
| assistance. But any codebase that lives more than a year
| and serves real users while generating revenue deserves to
| have engineers who knows what's happening beyond authoring
| markdown instructions to multiple agents.
|
| Your claim seems to push us towards a territory where
| externalizing out thought processes to a third party is the
| best possible outcome for all parties, because the models
| will only get better and stay just as affordable.
|
| I will respond to that by pointing out that, models that
| will ultimately be flawless in code generation will worth a
| fortune in terms of adding value, and any corporation that
| will win the arms race will be actually killing themselves
| by not raising the cost of access to their services by a
| metric ton. This is because there will be few LLM providers
| that actually worth it by then, and because oligopoly is a
| thing.
|
| So no. I don't expect that we'll ever reach a point where
| the average person will be "speaking forth" software the
| same way they post on Reddit, without paying cancer
| treatment levels of money.
|
| But even if it's actually affordable... Why would I ever
| want to use your app instead of just asking an LLM to make
| me one from scratch? No one seems to think about that.
| 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.
| 9dev wrote:
| > AI just means more output will be expected of you, and
| they'll keep pushing you to work as hard as you can.
|
| That's a bit too cynical for me. After all, yes, your boss
| is not paying you for sipping lattes, but for producing
| value for the company. If there is a tool that maximises
| your output, why wouldn't he want you to use that to great
| efficiency?
|
| Put differently, would a carpenter shop accept employees
| rejecting the power saw in favour of a hand saw to retain
| their artisanal capability?
| recursive wrote:
| If the power saw ran itself without any oversight, the
| carpenter shop wouldn't accept any type of employees.
| 9dev wrote:
| But that's the exact opposite of what the GP was arguing;
| you will be expected to stick with the agent more, not
| less.
| coldtea wrote:
| You or someone else might be expected. The rest will just
| be expected to be fired.
| palmotea wrote:
| > That's a bit too cynical for me. After all, yes, your
| boss is not paying you for sipping lattes, but for
| producing value for the company. If there is a tool that
| maximises your output, why wouldn't he want you to use
| that to great efficiency?
|
| Sitting in a cafe enjoying a latte is not "producing
| value for the company." If having "5 agents to generate a
| new SAAS-product" matches your non-AI capacity _and_
| gives you enough free time to relax in a cafe, he 's
| going to want to you run _50 agents_ generating _5_ new
| SAAS products, until you hit your capacity.
|
| If he doesn't need _5_ new SAAS products, just one, then
| he 's going to fire you or other members of your team.
|
| Think of it this way: you're a piece of equipment to your
| boss, and every moment he lets you sit idle (on the
| clock) is money lost. He wants to run that piece of
| equipment as hard as he can, to maximize his profit.
|
| That's labor under capitalism.
| vbezhenar wrote:
| > why wouldn't he want you to use that to great
| efficiency
|
| Because I deny that? It's not fun for me.
|
| > would a carpenter shop accept employees rejecting the
| power saw in favour of a hand saw to retain their
| artisanal capability?
|
| Why not? If that makes enough money to keep going.
|
| You might argue that in theoretical ideal market
| companies who're not utilizing every possible trick to
| improve productivity (including AI) will lose
| competition, but let's be real, a lot of companies are
| horribly inefficient and that does not make them
| bankrupt. The world of producing software is complicated.
|
| I know that I deliver. When I'm asked to write a code, I
| deliver it and I responsible for it. I enjoy the process
| and I can support this code. I can't deliver with AI. I
| don't know what it'll generate. I don't know how much
| time would it take to iterate to the result that I
| precisely want. So I can't longer be responsible for my
| own output. Or I'd spend more time baby-sitting AI than
| it would take me to write the code. That's my position.
| Maybe I'm wrong, they'll fire me and I'll retire, who
| knows. AI hype is real and my boss often copy&pasting
| ChatGPT asking me to argue with it. That's super stupid
| and irritating.
| gombosg wrote:
| I can totally relate to your experience.
|
| I started this career because I liked writing code. I no
| longer write a lot of code as a lead, but I use writing
| code to learn, to gain a deeper understanding of the
| problem domain etc. I'm not the type who wants to write
| specs for every method and service but rather explore and
| discover and draft and refactor by... well, coding. I'm
| amazed at creating and reading beautiful, stylish,
| working code that tells a story.
|
| If that's taken away, I'm not sure how I could retain my
| interest in this profession. Maybe I'll need to find
| something else, but after almost a decade this will be a
| hard shift.
| 9dev wrote:
| > Because I deny that? It's not fun for me.
|
| I totally emphasise as a fellow developer, but I doubt
| you realise what an incredibly privileged position it is
| to just refuse working if you don't _have fun_ doing it.
| And it doesn 't really make for a convincing argument to
| keep you employed either.
|
| > Why not? If that makes enough money to keep going.
|
| If all other competing carpenters use power tools, you're
| going to loose contracts. We've had a few incredibly easy
| decades as software developers where market pressure
| wasn't really a thing, but that is about to change when
| the cost of producing code drops considerably.
|
| > You might argue that in theoretical ideal market
| companies who're not utilizing every possible trick to
| improve productivity (including AI) will lose competition
| [...]
|
| You're moving the goalposts here. We're not talking about
| wringing every last drop of efficiency out of employees.
| We're talking about businesses not tolerating paying for
| licenses for AI agents to enable developers to sip Lattes
| while their computer does their job. That's a
| fundamentally different proposition.
| 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.
| gspr wrote:
| I hear you. And maybe you're right. Maybe I'm deluding
| myself, but: when I look at my skilled colleagues who
| vibecode, I can't understand how this is sustainable.
| They're smart people, but they've _clearly_ turned off.
| They can 't answer non-trivial questions about the
| _details_ of the stuff they (vibe-)delivered without
| asking the LLM that wrote it. Whoever uses the code
| downstream aren 't gonna stand (or pay!) for this long-
| term! And the skills of the (vibe-)authors will rapidly
| disappear.
|
| Maybe I'm just as naive as those who said that
| photographs lack the soul of paintings. But I'm not 100%
| convinced we're done for yet, if what you're actually
| selling is thinking, reasoning and understanding.
| shinycode wrote:
| The difference with a purely still photograph is that
| code is a functional encoding of an intention. Code of an
| LLM could be perfect and still not encode the perfect
| intention of the product. I've seen that in many
| occasions. Many people don't understand what code really
| is about and think they have a printer toy now and we
| don't have to use pencils. That's not at all the same
| thing. Code is intention, logic, specific use case all at
| once. With a non deterministic system and vague prompting
| there will be misinterpreted intentions from LLM because
| the model makes decisions to move forward. The problem is
| the scale of it, we're not talking about 1000 loc. In a
| month you can generate millions of loc, in a year
| hundreds of millions of loc.
|
| Some will have to crash and burn their company before
| they realize that no human at all in the loop is a non
| sense. Let them touch fire and make up their mind I
| guess.
| raw_anon_1111 wrote:
| > _Code is intention, logic, specific use case all at
| once. With a non deterministic system and vague prompting
| there will be misinterpreted intentions from LLM because
| the model makes decisions to move forward. The problem is
| the scale of it, we're not talking about 1000 loc. In a
| month you can generate millions of loc, in a year
| hundreds of millions of loc._
|
| People are also non deterministic. When I delegate work
| to team of five or six mid level developers or God forbid
| outsourced developers, I'm going to have to check and
| review their work too.
|
| It's been over a decade that my vision/responsibility
| could be carried out by just my own two hands and be done
| on time within 40 hours a week - until LLMs
| gspr wrote:
| People are indeed not deterministic. But they are
| accountable. In the legal sense, of course, but more
| importantly, in an interpersonal sense.
|
| Perhaps outsourcing is a good analogy. But in that case
| I'd call it outsourcing without accountability. LLMs feel
| more like an infinite chain of outsourcing.
| raw_anon_1111 wrote:
| As a former tech lead and now staff consultant who leads
| cloud implementations + app dev, _I_ am ultimately
| responsible for making sure that projects are done on
| time, on budget and meets requirements. My manager nor
| the customer would allow me to say it's one of my team
| members fault that something wasn't done correctly any
| more than I could say don't blame me blame Codex.
|
| I've said repeatedly over the past couple of days that if
| a web component was done by someone else, it might as
| well have been created by Claude, I haven't done web
| development in a decade. If something isn't right or I
| need modifications I'm going to either have to Slack the
| web developer or type a message to Claude.
| shinycode wrote:
| Ofc people are non deterministic. But usually we expect
| machines to be. That's why we trust them blindly and
| don't check the calculations. We review people's work all
| the time though. Here people will stop review machine LLM
| code as it's kind of a source of truth like in other
| areas. That's my point, reviewing code takes time and
| even more time when no human wrote it. It's a dangerous
| path to stop reviews because of trust in the machine now
| that the machine is just kind of like humans, non
| deterministic.
| raw_anon_1111 wrote:
| No one who has any knowledge or who has ever used an LLM
| expects determinism.
|
| And there are no computer professionals who haven't heard
| about hallucinations.
|
| Reviewing whether the code meets requirements through
| manual and automated tests - and that's all I cared about
| when I had a team of 8 under me - is the same regardless.
| I wasn't checking whether John used a for loop or while
| loop in between my customer meetings and meetings with
| the CTO. I definitely wasn't checking the SOQL (not a
| typo) of the Salesforce consultants we hired. I was
| testing inputs and outputs and UX.
| skydhash wrote:
| There are so many types of requirements though. Security
| is one, performance is another. No one has cared about
| while/for for a long time.
| raw_anon_1111 wrote:
| Okay - and the person ultimately leading the team is
| still responsibility for it whether you are delegating to
| more junior developers or AI. You're still reviewing
| someone else's code based on your specs
| andhuman wrote:
| I have this nagging feeling I'm more and more skimming
| text, not just what the LLMs output, but all type of
| texts. I'm afraid people will get too lazy to read, when
| the LLM is almost always right. Maybe it's a silly
| thought. I hope!
| gspr wrote:
| This is my fear too.
|
| People will say "oh, it's the same as when the printing
| press came, people were afraid we'd get lazy from not
| copying text by hand", or any of a myriad of other
| innovations that made our lives easier. I think this time
| it's different though, because we're talking about
| offloading the very essence of humanity - thinking. Sure,
| getting too lazy to walk after cars became widespread was
| detrimental to our health, but if we get too lazy to
| think, what are we?
| agumonkey wrote:
| there are some youtube videos about the topic, be it
| pupil in high school addicted to llms, or adults losing
| skills, and not dev only, society is starting to see
| strange effects
| atentaten wrote:
| Can you provide links to these videos?
| agumonkey wrote:
| This one is in french (hope you don't mind),
| https://youtu.be/4xq6bVbS-Pw?t=534 mentions the issues
| for students and other cognitive issues.
| dextrous wrote:
| After a multi-decade career that spanned what is rapidly
| seeming like the golden age of software development, I
| have two emotions: first gratefulness; second a mixture
| of resignation, maudlin reflection, and bitterness that I
| am fighting hard to resist.
|
| As someone who's always wanted to "get home and code
| something on my own", I do have a glimmer of hope that I
| wonder if others share. I've worked extensively with
| Claude and there's no question I am now a high velocity
| "builder" and my broad experience has some value here. I
| am sad that I won't be able to deeply look at all the
| code I am producing, but I am making sure the LLM and I
| structure things so that I could eventually dig in to
| modules if needed (unlikely to happen I suppose).
|
| Anyway, my hope/question: if I embrace my new role as
| fast system builder and I am creative in producing
| systems that solve real problems "first", is there a path
| to making that a career (I.e. 4 friends and I cranking
| out real production software that's filling a real
| niche)? There must be some way for this to succeed --- I
| am not yet buying the "everything will be instantly
| copyable and so any solution is instantly commodity"
| argument. If that's true, then there is no hope. I am
| still in shape, though, so going pro in pickleball is
| always an option, ha ha.
| samiv wrote:
| Unfortunately you aren't a high velocity builder. The
| velocity curve has now shifted and everyone having Claude
| blast out loc after loc is now a high velocity builder.
| And when everyone is a high velocity builder...nobody is.
| dextrous wrote:
| "And when everyone's super, no one will be".
|
| Fair point, but my hope is that the creativity involved
| in deciding what to build, with the choice informed by
| engineering experience (the project/value will not be
| obvious to everyone) will allow differentiation.
| samiv wrote:
| "creativity involved in deciding what to build, with the
| choice informed by engineering experience (the
| project/value will not be obvious to everyone) will allow
| differentiation."
|
| How? Anyone upon seeing your digital product can just
| prompt the same thing in no time. If you can prompt it, I
| can prompt it and so can a million other people.
|
| Nobody whether an individual or business holds any
| uniqueness or advantage to themselves. All careers and
| skill sets are leveled and worthless. Implementation
| skills are worthless. Creativity is worthless.
|
| The only valuable thing is data.
| dextrous wrote:
| Agree on data value, but as mentioned above I am not yet
| buying the "everything will be instantly copyable and so
| any solution is instantly commodity" argument ... crud
| web-app sure, something with significant back-end
| complexity or a multi-service systems level solution, not
| so much. Perhaps optimistic, admittedly. Cheers.
| stareatgoats wrote:
| Somehow I appreciate this type of attitude more than the
| one which reflects total denial of the current
| trajectory. Fervent denial and AI trash-talking being
| maybe the single most dominant sentiment on HN over the
| last year, by all means interspersed with a fair amount
| of amazement at our new toys.
|
| But it is sad if good programmers should loose sight of
| the opportunities the future will bring (future as in the
| next few decades). If anything, software expertise is
| likely to be one of the most sought-after skills - only a
| slightly different kind of skill than churning out LOCs
| on a keyboard faster than the next person: People who can
| harness the LLMs, design prompts at the right abstraction
| level, verify the code produced, understand when someone
| has injected malware, etc. These skills will be extremely
| valuable in the short to medium term AFAICS.
|
| But ultimately we will obviously become obsolete if
| nothing (really) catastrophic happens, but when that
| happens then likely all human labor will be obsolete too,
| and society will need to be organized differently than
| exchanging labor for money for means of sustenance.
| agumonkey wrote:
| I get crazy over the 'engineer are not paid to write
| loc', nobody is sad because they don't have to type
| anymore. My two issues are it levels the delivery game,
| for the average web app, anybody can now output something
| acceptable, and then it doesn't help me conceptualize
| solution better, so I revert to letting it produce stuff
| that is not maleable enough.
| majormajor wrote:
| I wonder about who "anybody can now output something
| acceptable" will hit most - engineers or software
| entrepreneurs.
|
| Any implementation moat around rapid prototyping, and any
| fundraising moat around hiring a team of 10 to knock out
| your first few versions, seems gone now. Trying to sell
| MVP-tier software is real hard when a bunch of your
| potential customers will just think "thanks for the idea,
| I'll just make my own."
|
| The crunch for engineers, on the other hand, seems like
| that even if engineers are needed to "orchestrate the
| agents" and manage everything, there could be a feature-
| velocity barrier for the software that you _can_ still
| sell (either internally or externally). Changing stuff
| more rapidly can quickly hit a point of limited ROI if
| users can 't adjust, or are slowed by constant
| tooling/workflow churn. So at some point (for the first
| time in many engineers' career, probably) you'll probably
| see product say "ok even though we built everything we
| want to test, we can't roll it all out at once!". But
| maybe what is learned from starting to roll those things
| out will necessitate more changes continually that will
| need some level of staffing still. Or maybe cheaper code
| just means ever-more-specialized workflows instead of
| pushing users to one-size-fits-all tooling.
|
| In both of those cases the biggest challenge seems to be
| "how do you keep it from toppling down over time" which
| has been the biggest unsolved problem in consumer
| software development for decades. There's a prominent
| crowd right now saying "the agents will just manage it by
| continuing to hack on everything new until all the old
| stuff is stable too" but I'm not sure that's entirely
| realistic. Maybe the valuable engineering skills will be
| putting in the right guardrails to make sure that
| behavioral verification of the code is a tractable
| problem. Or maybe the agents will do that too. But right
| now, like you say, I haven't found particularly good
| results in conceptualizing better solutions from the
| current tools.
| agumonkey wrote:
| > your potential customers will just think "thanks for
| the idea, I'll just make my own."
|
| yeah, and i'm surprised nobody talks about this much.
| prompting is not that hard, and some non software people
| are smart enough to absorb the necessary details
| (especially since the llm can tutor them on the way) and
| then let the loop produce the MVP.
|
| > Or maybe cheaper code just means ever-more-specialized
| workflows instead of pushing users to one-size-fits-all
| tooling.
|
| Interesting thought
| almostdeadguy wrote:
| If the world comes to that it will be absolutely
| catastrophic, and it's a failure of grappling with the
| implications that many of the executives of AI companies
| think you can paper over the social upheaval with some
| UBI. There will be no controlling what happens, and you
| don't even need to believe in some malicious autonomous
| AI to see that.
| Wobbles42 wrote:
| I feel the same.
|
| Frankly, I am not sure there is a place in the world at
| all for me in ten years.
|
| I think the future might just be a big enough garden to
| keep me fed while I wait for lack of healthcare access to
| put me out of my misery.
|
| I am glad I am not younger.
| untrust wrote:
| Imagine everyone who is in less technical or skilled
| domains.
|
| I can't help but resist this line of thinking as a
| result. If the end is nigh for us, it's nigh for everyone
| else too. Imagine the droves of less technical workers in
| the workforce who will be unseated before software
| engineers. I don't think it is tenable for every worker
| in the first world to become replaced by a computer. If
| an attempt at this were to occur, those smart unemployed
| people would be a real pain in the ass for the oligarchs.
| sdf2erf wrote:
| So why havent you been fired already?
|
| .......
| agumonkey wrote:
| gemini has only been deployed in the corp this year, but
| the expectations are now higher (doubled). i'll report by
| the end of the year..
| Der_Einzige wrote:
| Yup. The majority of this website is going to find out
| they were grossly overpaid for a long time.
| anjel wrote:
| 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.
| samiv wrote:
| I feel the same. And I expect even a lot of the early
| adopters and AI enthusiasts are going to find themselves
| as the short end of the stick sooner than later.
|
| "Oops I automated myself out a job".
| agumonkey wrote:
| I've already seen this play out. The lazies in our floor
| were all crazy about AI because they could finally work
| few and finish their tasks. Until they realized that they
| were visibly replaceable now. The motto in team chats is
| "we'll lie about the productivity gains to management,
| just say 10% but with lots of caretaking" now
| 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.
| recursive wrote:
| Static type checking is even faster than running the
| code. It doesn't catch everything, but if finding a type
| error in a fast test is good, then finding it before
| running any tests seems like it would be even better.
| rapind wrote:
| 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.
| Wobbles42 wrote:
| Companies aren't evaluating on "keeping an eye on
| technical debt", but then ARE directly evaluating on
| whether you use AI tools.
|
| Meanwhile they are hollowing out work forces based on
| those metrics.
|
| If we make doing the right thing career limiting this all
| gets rather messy rather quickly.
| joquarky wrote:
| > If we make doing the right thing career limiting this
| all gets rather messy rather quickly.
|
| This has already happened. The gold rush brogrammers have
| taken over.
|
| Careers are over. Company loyalty is a relic. Now it's a
| matter of adapting quickly to earn enough to survive.
| ensemblehq wrote:
| I can provide evidence for your claim. The technical debt
| can easily snowball if the review process is not
| stringent enough to keep out unnecessary functions.
| wtetzner wrote:
| > the cost-benefit analysis clearly favors letting these
| tools rip
|
| Does it? I have yet to see any evidence that they are a net
| win in terms of productivity. It seems to just be a feeling
| that it's more efficient.
| 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.
| p1esk wrote:
| I don't read or edit the code my claude code agent
| produces. That's its job now. My job is to organize the
| process and get things done.
| shinycode wrote:
| In this case why can't other agents just automate your
| job completely ? They are capable of that. What do you
| bring in the process of still doing manual organization ?
| p1esk wrote:
| I still have to tell it what to do, and often how to do
| it. I manage its external memory and guidelines, and
| review implementation plans. I'm still heavily involved
| in software design and test coverage.
|
| AI is not capable yet of automating my job completely - I
| anticipate this will happen within two years, maybe even
| this year (I'm an ML researcher).
| shinycode wrote:
| Do you mean, from your perspective, within 2 years humans
| won't be able to bring anything of value to the equation
| in management and control ?
| p1esk wrote:
| No, I mean that my job in its current form - as an ML
| researcher with a phd and 15 years of experience - will
| be completely automated within two years.
| fauigerzigerk wrote:
| If you want a machine (or in fact another human) to do
| something for you, there are two tasks you cannot
| delegate to them:
|
| a) Specify what you want them to do.
|
| b) Check if the result meets your expectations.
|
| Does your current job include neither a nor b?
| p1esk wrote:
| A/B happen at different abstractions levels. My
| abstraction level will be automated. My manager's level
| will probably last another year or so.
| fauigerzigerk wrote:
| So your assumption is that it will ultimately be the
| users of software themselves who will throw some every
| day language at an AI and it will reliably generate
| something that meets those users' intuitive expectations?
| p1esk wrote:
| Yes, it will be at least as reliable as an average
| software engineer at an average company (probably more
| reliable than that), or at least as reliable as a self-
| driving car where a user says get me to this address, and
| the car does it better (statistically) than an average
| human driver.
| fauigerzigerk wrote:
| I think this could work for some tasks but not for
| others.
|
| We didn't invent formal languages to give commands to
| computers. We invented them as a tool for thinking and
| communicating things that are hard to express in natural
| language.
|
| I doubt that we will stop thinking and I doubt that it
| will ever be efficient to specify tasks purely in terms
| of natural language.
|
| One of my first jobs as a software engineer was for a
| bank (~30 years ago). This bank manager wasn't a man of
| many words. He just handed us an Excel sheet as a
| specification for what he wanted us to implement.
| p1esk wrote:
| My job right now is to translate natural English
| statements from my bosses/colleagues into natural English
| instructions for Claude. Yes, it takes skill and
| experience to do this effectively. But I don't see any
| reasons Gemini 4, Opus 5 or GPT-6 won't be able to do
| this just as well as I do.
| dw_arthur wrote:
| Is the progress of LLMs moving up abstraction layers
| inevitable as they gather more data from each layer?
| First, we fed LLMs raw text and code and now they are
| gathering our interactions with the LLM regarding
| generated code. It seems like you could then use the
| interactions to make a LLM that is good at prompting and
| fixing another LLMs generated code. Then its on to the
| next abstraction layer.
| p1esk wrote:
| What you described makes sense, and it's just one of the
| things to try. There are lots of other research
| directions: online learning, more efficient learning,
| better loss/reward functions, better world models from
| training on Youtube/VR simulations/robots acting in real
| world, better imitation learning, curriculum learning,
| etc. There will undoubtedly be architectural
| improvements, hardware improvements, longer context
| windows, insights from neuroscience, etc. There is still
| so much to research. And there are more AI researchers
| now than ever. Plus current AI models already make us (AI
| researchers) so much more productive. But even if
| absolutely no further progress is made in AI research,
| and foundational model development stops today, there's
| so much improvement to be made in the tooling around the
| models: agentic frameworks, external memory management,
| better online search, better user interactions, etc. The
| whole LLM field is barely 5 years old.
| candiddevmike wrote:
| What are you going to do for work in 2 years?
| p1esk wrote:
| I have enough savings for a few years, so I might just
| move to a lower COL area, and wait it out. Hopefully
| after the initial chaos period things will improve.
| dadandang wrote:
| simonw alert!!!
| elzbardico wrote:
| There were always many mediocre engineers around, some of
| them even with fancy titles like "Senior," "Principal", and
| CTO.
|
| We have always survived it, so probably we can also survive
| mediocre coders not reading the code the LLM generates for
| them because they are unable to see the problems that they
| were never able to see in their handwritten code.
| therealdrag0 wrote:
| Honestly it's not that hard. I already coded less and less
| as part of my job as I get more senior and just didn't have
| time, but I was still easy to do code reviews and fix bugs,
| sit down and whip out a thousand lines in a power session.
| Once you learn it doesn't take much practice to maintain
| it. A lot of traditional coding is very inefficient. With
| AI it's like we're moving from combustion cars to EVs, the
| energy efficiency is night and day, for doing the same
| thing.
|
| That said, the next generation may struggle, but they'll
| find their way.
| ensemblehq wrote:
| It's going to be extremely difficult if PR and code reviews
| do not prune unnecessary functions. From what I'm
| experiencing now, there's a lot of additional code that
| gets generated.
| 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
| cowlby wrote:
| Alternatively, another second order effect is can't sip
| latte anymore because you're orchestrating 8 bots do the
| work and you're back to 80%-100% time saturation.
| coldtea wrote:
| The previous second order effect is more likely. For the
| one orchestrating 8 bots, 7 others are not needed
| anymore.
| dagss wrote:
| Or, there is just a lot more software written as the
| costs drop. I think most people work with software not
| tailored enough for their situation..
| coldtea wrote:
| > _Or, there is just a lot more software written as the
| costs drop._
|
| Yeah, no, that's wishful thinking. The companies will
| just opt for higher margins.
| jochem9 wrote:
| So far in my career I have always had more requests
| coming in than implementations going out. If I can go 3
| or 10 times faster, than I will still have plenty of
| work. Especially for the slew of ideas that are never
| even considered to put towards a dev, because it's
| already considered to be too low value to have it even be
| considered to be build. Or the ideas that are so far
| fetched they were never considered feasible. I am not
| worried work will dry up.
|
| What I believe is going to be interesting is what happens
| when non-engineers adopt building with agentic AI. Maybe
| 70 or 80% of their needs will be met without anyone else
| directly involved. My suspicion is that it will just
| create more work: making those generated apps work in a
| trustworthy manner, giving the agents more access to
| build context and make decisions, turning those one off
| generated apps into something maintainable, etc.
| meetingthrower wrote:
| This 100%. We want MOAR!!!
| samiv wrote:
| Exactly this. Even if right now you, bottom level wage
| earning grunt, get to lighten your workload for a fleeting
| second, sit back and enjoy the latte it's only but a
| fleeting second until the capital class tighten the screws.
|
| Most people will get laid off and made redundant and those
| who remain are going to have to run faster than ever to
| produce wealth for the capital owners.
| victorbjorklund wrote:
| Yea, I don't think that will be the case. Spreadsheets
| simplified the work of junior finance people who did all
| the work by hand before. But more people work in finance
| now than before.
| joquarky wrote:
| My think/create/solve focus is on making my agentic coding
| environment produce high quality code with the least cost.
| Seems like a technical challenge worth playing with.
|
| It probably helps that I have 40 years of experience with
| producing code the old ways, including using punch cards in
| middle school and learning basic on a computer with no
| persistent storage when I was ten.
|
| I think I've done enough time in the trenches and deserve to
| play with coding agents without shame.
| re-thc wrote:
| > I see people at work who are drooling about being able to
| have code made for them
|
| These people just drool at being able to have work done for
| them to begin with. Are you sure it is just "code"?
| gedy 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.
|
| In my circles see some overlap with the people who are like:
| "Done! Let's move on" and don't worry about production bugs,
| etc. "We'll fix it later".
|
| I've always stressed out about introducing bugs and want to
| avoid firefighting (even in orgs where that's the way to get
| noticed).
|
| Too much leaning on coding tools and agents feels to sketchy
| to someone like me right now (maybe always tbh)
| cyber_kinetist wrote:
| Actually for me it was the opposite: before I wasn't able to
| play around and experiment in my free time that much, because
| I didn't have enough energy left to actualize the thoughts
| and ideas I have since I have a day job.
|
| Now, since the bottleneck of moving the fingers to write code
| has gone down, I actually started to enjoy doing side
| projects. The mental stress from writing code has gone down
| drastically with Claude Code, and I feel the urge to create
| more nowadays!
| agumonkey wrote:
| you have a point.. i'm still confused about how this will
| affect jobs, markets
|
| in a way a personal project is different from a job duty,
| here you're exploring, less if no deadline.. at work if I
| feel the llm is doing everything and I don't really master,
| i risk my job and my skills rot.
| dickersnoodle 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.
|
| +100 for this.
| 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.
| andrekandre wrote:
| > 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.
|
| yea, same here.
|
| i've asked an ai to plan and setup some larger non straight
| forwards changes/features/refactorings but it usually
| devolves into burning tokens and me clicking the 'allow'
| button and re-clarifying over and over when it keeps trying
| to confirm the build works etc...
|
| when i'm stuck though, or when im curious of some solution it
| usually opens the way to finish the work similar to stack
| overflow
| 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.
| mejutoco wrote:
| > Learning to plan things out in your head
|
| I dont think any complex plan should be planned in your head.
| But drawing diagrams, sketching components, listing pros and
| cons, 100%. Not jumping directly into coding might look more
| like jumping into spec writing a poc
| Nasrudith wrote:
| Maintaining a 'mental RAM Cache' is a powerful tool to
| understanding the system as a whole on a deep and intuitive
| level, even if you can only 'render' sections at a time.
| The bigger it is the more you can keep track of to be able
| to foresee interactions between distant pieces.
|
| It shouldn't be your only source of a plan as you'd likely
| wind up dropping something, but figuring out how to jiggle
| things around before getting it 'on paper' is something
| I've found helpful.
| mejutoco wrote:
| Following the RAM analogy, this sounds like saving files
| only in RAM, instead of creating the files in the file
| system, persisted on disk, and then caching it in RAM.
|
| Personally, for me without writing or sketching I cannot
| think complex things: as in complex logic, constraints,
| etc.
|
| I guess this is topic too abstract, so we can read into
| it different things.
| 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.
| positron26 wrote:
| So now we're pro-slaughter and low-yield agriculture as
| long as we get to ride the keyboard eh?
| 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 couple of 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
| gchamonlive wrote:
| > A lot of how I form my thoughts is driven by writing code,
| and seeing it on screen, running into its limitations.
|
| If you need that, don't use AI for it. What is it that you
| don't enjoy coding or think it's tangential to your thinking
| process? Maybe while you focus on the code have an agent build
| a testing pipeline, or deal with other parts of the system that
| is not very ergonomic or need some cleanup.
| andrekandre wrote:
| > If you need that, don't use AI for it.
|
| this is the right answer, but many companies mandate to use
| ai (burn x tokens and y percent of code) now, so people are
| bound to use it where it might not fit
| Wobbles42 wrote:
| I sometimes wonder if the economics of AI coding agents only
| work if you totally ignore all the positive externalities that
| come with writing code.
|
| Is the entire AI bubble just the result of taking performance
| metrics like "lines of code written per day" to their logical
| extreme?
|
| Software quality and productivity have always been notoriously
| difficult to measure. That problem never really got solved in a
| way that allowed non technical management to make really good
| decisions from the spreadsheet level of abstraction... but
| those are the same people driving adoption of all these AI
| tools.
|
| Engineers sometimes do their jobs in spite of poor incentives,
| but we are eliminating that as an economic inefficiency.
| majormajor wrote:
| Historically software engineering has been seen as "assembly
| line" work by a lot of people (see all the efforts to outsource
| it through spec handoffs and waterfall through the years) but
| been implemented in practice as design-as-you-build (nobody
| anticipates all the questions or edge cases in advance,
| software specs are often an order of magnitude simpler than the
| actual number of branches in the code).
|
| For mission-critical applications I wonder if making "writing
| the actual code" so much cheaper means that it would make more
| sense to do more formal design up front instead, when you no
| longer have a human directly in the loop during the writing of
| the code to think about those nasty pops-up-on-the-fly
| decisions.
| wes-k wrote:
| > software specs are often an order of magnitude simpler than
| the actual number of branches in the code
|
| Love this! Be it design specs or a mock from the designer. So
| many unaccounted for decisions. Good devs will solve many on
| their own, uplevel when needed, and provide options.
|
| And absolutely it means more design up front. And without
| human in the direct loop, maybe people won't skimp on this!
| bitwize wrote:
| 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.
| tiny-automates wrote:
| i go back and forth on this. when i'm working on something
| where the hard part is the actual algorithm, say custom
| scheduling logic or a non-trivial state machine, i need my
| hands in the code because the implementation is the thinking.
| but for anything where the complexity is in integration rather
| than logic, wiring up OAuth flows, writing CRUD endpoints,
| setting up CI pipelines, agents save me hours and the output is
| usually fine after one review pass. the "code as thought"
| argument is real but it applies to maybe 20% of what most of us
| ship day to day. the other 80% is plumbing where the bottleneck
| is knowing what to build, not how.
| mcny wrote:
| > A lot of how I form my thoughts is driven by writing code,
| and seeing it on screen, running into its limitations.
|
| I completely agree but my thought went to how we are supposed
| to estimate work just like that. Or worse, planning poker where
| I'm supposed to estimate work someone else does.
| AdieuToLogic wrote:
| > A lot of how I form my thoughts is driven by writing code,
| and seeing it on screen, running into its limitations.
|
| Two principles I have held for many years which I believe are
| relevant both to your sentiment and this thread are reproduced
| below. Hopefully they help.
|
| First: When making software, remember that it
| is a snapshot of your understanding of the problem. It
| states to all, including your future-self, your
| approach, clarity, and appropriateness of the solution
| for the problem at hand. Choose your statements wisely.
|
| And: Code answers what it does, how it does it,
| when it is used, and who uses it. What it cannot answer
| is why it exists. Comments accomplish this. If a
| developer cannot be bothered with answering why the code
| exists, why bother to work with them?
| 8fu8uf8 wrote:
| > If a developer cannot be bothered with answering why the
| code exists, why bother to work with them?
|
| Most people can't answer why they themselves exist, or
| justify why they are taking up resources rather than eating a
| bullet and relinquishing their body-matter.
|
| According to the philosophy herein, they are therefore
| worthless and not worth interacting with, right?
| raw_anon_1111 wrote:
| To your first point - so are my many markdown files that I
| tell Codex/Claude to keep updated while I'm doing my work
| including telling them to keep them updated with why I told
| them to do certain things. They have detailed documentation
| of my initial design goals and decisions that I wrote myself.
|
| Actually those same markdown files answer the second
| question.
| whoisthemachine wrote:
| It's almost like programming via markdown.
| raw_anon_1111 wrote:
| Or like every tech lead has had to do when documenting
| specifications for a team...
| carlmr wrote:
| >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.
|
| This is so on point. The spec as code people try again and
| again. But reality always punches holes in their spec.
|
| A spec that wasn't exercised in code, is like a drawing of a
| car, no matter how detailed that drawing is, you can't drive
| it, and it hides 90% of the complexity.
|
| To me the value of LLMs is not so much in the code they write.
| They're usually to verbose, start building weird things when
| you don't constantly micromanage them.
|
| But you can ask very broad questions, iteratively refine the
| answer, critique what you don't like. They're good as a
| sounding board.
| gombosg wrote:
| I love using LLMs as well as rubber ducks - what does this
| piece of code do? How would you do X with Y? etc.
|
| The problem is that this spec-driven philosophy (or hype, or
| mirage...) would lead to code being entirely deprecated, at
| least according to its proponents. They say that using LLMs
| as advisors is already outdated, we should be doing fully
| agentic coding and just nudge the LLM etc. since we're losing
| out on 'productivity'.
| carlmr wrote:
| >They say that using LLMs as advisors is already outdated,
| we should be doing fully agentic coding and just nudge the
| LLM etc. since we're losing out on 'productivity'.
|
| As long as "they" are people that either profit from FOMO
| or bad developers that still don't produce better software
| than before, I'm ok ignoring the noise.
| roysting wrote:
| I liken it to manual versus automated industrial production. I
| think manual coding will always have its place just like how
| there are even still people who craft things by manual labor,
| whether it's woodworkers only using manual tools or blacksmiths
| who still manually stoke coke fires that produce very unique
| and custom products; vs the highly automated production lines
| we have that produce acceptable forms of something efficiently,
| and many of them so many people can have them.
| keepamovin wrote:
| I think of it differently: I've been coding so long that
| ironing out the details and working through the specification
| with AI comes extremely naturally. It's like how I would talk
| to a colleague and iterate on their work. However, the quality
| of the code produced by LLMs needs to be carefully managed to
| assure it's of a high standard. That's why I formalized a
| system of checks and balances for my genetic coding that
| contains architectural guidelines as well as language, specific
| taste advice.
|
| You can check it out here: https://ai-lint.dosaygo.com/
| mrklol wrote:
| I am similar but I think we just have to adjust. Learn and
| improve writings specs with all the details.
| ensemblehq wrote:
| This is exactly the issue I'm facing especially when working
| with AI-generated codebases.
|
| Coding is significantly faster but my understanding of the
| system takes a lot longer because I'm having to merge my mental
| model with what was produced.
| mym1990 wrote:
| Some people like to lay the brick, some people like to draw the
| blueprints. I don't think there is anything wrong with not
| subscribing to this onslaught on AI tooling, doing the hard
| work is rewarding. Whether AI will become a standard in how
| code is written in the future is still to be determined and I
| think there is a real chance that is where it goes, it
| shouldn't hinder your love for doing what you do.
| jon_north wrote:
| 100%. To me the real question is whether all the bother
| getting the agents to not waste time nets out to real gains,
| or perceived gains (while possibly even losing efficiency).
|
| It's not at all clear to me which is true given the level of
| hype and antipathy out there. I'm just going to watch and
| wait, and experiment cautiously, till it's more clearcut.
| mycall wrote:
| Same reason people build their own homes by hand, for the
| challenge because YOLO.
| 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.
| gombosg wrote:
| I think there are four fundamental issues here for us...
|
| 1. There are actually less software jobs out there, with
| huge layoffs still going on, so software engineering as a
| profession doesn't seem to profit from AI.
|
| 2. The remaining engineers are expected by their
| employers to ship more. Even if they can manage that
| using AI, there will be higher pressure and higher stress
| on them, which makes their work less fulfilling, more
| prone to burnout etc.
|
| 3. Tied to the previous - this increases workism,
| measuring people, engineers by some output benchmark
| alone, treating them more like factory workers instead of
| expert, free-thinking individuals (often with higher
| education degrees). Which again degrades this profession
| as a whole.
|
| 3. Measuring developer productivity hasn't really been
| cracked before either, and still after AI, there is not a
| lot of real data proving that these tools actually make
| us more productive, whatever that may be. There is only
| anecdotal evidence: I did this in X time, when it would
| have taken me otherwise Y time - but at the same time
| it's well known that estimating software delivery
| timelines is next to impossible, meaning, the estimation
| of "Y" is probably flawed.
|
| So a lot of things going on apart from "the world will
| surely need more software".
| whynotminot wrote:
| I don't see how anything you're saying is a response to
| what I said.
| pickleRick243 wrote:
| Do you have this same understanding for all the people
| whose livelihoods are threatened (or already extinct) due
| to the work of engineers?
| falloutx wrote:
| Yes, but who did we automate out of a job by building
| crappy software? Accountants are more threatened by AI
| than any of the software we created before, same with
| Lawyers, teachers. We didnt automate any physical
| labourers out of a job too.
| bopbopbop7 wrote:
| Where is all the amazing software and/or improvements in
| software quality that is supposed to be coming from this
| revolution?
|
| So far the only output is the "How I use AI blogs", AI
| marketing blogs, more CVEs, more outages, degraded software
| quality, and not much of shipping anything.
|
| Is there any examples of real products and not just
| anecdotes of "I'm 10x more productive!"?
| whynotminot wrote:
| Sounds like a skill issue. I've seen it rapidly increase
| the speed of delivery in my shop.
| osn9363739 wrote:
| Why is it so hard to find examples?
| whynotminot wrote:
| You're asking to see my company's code base?
|
| It's not like with AI we're making miraculous things
| you've never seen before. We're shipping the same kinda
| stuff just much faster.
|
| I don't know what you're looking for. Code is code it's
| just more and more being written by AI.
| EagnaIonat wrote:
| I was in the same mindset until I actually took the
| Claude code course they offer. I was doing so much wrong.
|
| The two main takeaways. Create a CLAUDE.md file that
| defines everything about the project. Have Claude feed
| back into the file when it makes mistakes and how to fix
| them.
|
| Now it creates well structured code and production level
| applications. I still double check everything of course,
| but the level of errors is much lower.
|
| An example application it created from a CLAUDE.md I
| wrote. The application reads multiple PDF's, finds the
| key stakeholders and related data, then generates a
| network graph across those files and renders it in an
| explorable graph in Godot.
|
| That took 3 hours to make, test. It also supports OpenAI
| (lmstudio), Claude and Ollama for its LLM callouts.
|
| What issue I can see happening is the duplication of
| assets in work. Instead of finding an asset someone
| built, people have been creating their own.
| 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.
| bigstrat2003 wrote:
| 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.
| Akranazon wrote:
| When is the last time someone said that, motivating you to
| try the latest model? If it was 6 or more month ago, my
| reply is that the sentiment expressed was partially
| incorrect in the past, but it is not incorrect now. If a
| conspiracy theorist is always wrong about a senior citizen
| being killed, that does not make the senior immortal.
| 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.
| bopbopbop7 wrote:
| I heard that about NFTs not long ago.
| einpoklum wrote:
| So, I went and did that:
|
| https://en.wikipedia.org/wiki/Luddite
|
| > _workers who opposed the use of certain types of automated
| machinery due to concerns relating to worker pay and output
| quality... Luddites were not opposed to the use of machines
| per se (many were skilled operators in the textile industry);
| they attacked manufacturers who were trying to circumvent
| standard labor practices of the time._
| 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.
| Nasrudith wrote:
| What do we want? Meaningless preventable toil! When do we
| want it? Now!
| kergonath wrote:
| Nobody wants meaningless preventable toil. What people
| want is a living. Nobody would be afraid of AI taking
| their jobs if it didn't mean that they'd get fired.
| ppoooNN wrote:
| I'll believe it when those same engineers fix CC's awful
| performance (mostly kidding, though I do wonder why they can't.
| Feels like it's doable).
|
| In reality that man is hoping to IPO in 6-12 months, if anyone
| is wondering why the "use claude or you're left behind" is so
| heavy right now.
| anonnon wrote:
| The enthusiasm so many devs show for it is also quite bizarre,
| saying things like "AI makes _me_ so much more productive, "
| with the implication that _they_ will be its primary
| beneficiaries, and that it won 't result in a massive reduction
| in demand, compensation, and status for developers, adversely
| affecting them. Even more bizarre when you realize these devs
| aren't the ones optimizing some popular video codec or writing
| avionics software for a fighter jet, but instead gluing
| together NPM packages--probably the first or second rung on on
| the software "innovator's dilemma" ladder of disruption.
| 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.
| chrisjj wrote:
| > By the time you do everything outlined here you've basically
| recreated waterfall and lost all speed advantage.
|
| Next: vibe brain surgery.
|
| /i
| aeonik wrote:
| Brain surgery is probably a bad example... or maybe a good
| one, but for different reasons?
|
| Brain surgery is highly technical AND highly vibe based.
|
| You need both in extremely high quantities. Every brain is
| different, so the super detailed technical anatomies that we
| have is never enough, and the surgeon needs constant feedback
| (and insanely long/deep focus).
| 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.
| jatora wrote:
| A good bit of scaffolding and babysitting allows you to let the
| model run much faster and more efficiently. Building your tool
| faster. I don't code to code, I code to build something I want.
| Forge36 wrote:
| I'm still writing code. I'm doing it to solve a problem,
| there's more to writing code than than typing. Recently AI
| massively simplified "getting started", and all of the tips
| here are applicable to working well on a team.
|
| My recent experience: I'm porting an app to Mac. It's been in
| my backlog for ~2 years. With Claude I had a functional
| prototype in under a day getting the major behavior
| implemented. I spent the next two weeks refactoring the
| original app to share as much logic as possible. The first two
| days was lots of fun. The refactoring was also something I
| wanted to flush out unit tests, still enjoyable.
|
| The worst part was debugging really bugs introduced to my code
| from 5 years ago. My functions had naming issues describing the
| behavior wrong, confusing Claude, that I needed to re-
| understand to add new features.
|
| Parts of coding are frustrating. Using AI is frustrating for
| different reasons.
|
| The most frustrating part was rebasing with git to create a
| sensible history (which I've had to do without AI in the past),
| reviewing the sheer volume of changes (14k lines) and then
| deciding "do I want my name on this" which involved cleaning up
| all the linter warnings I'd self imposed on myself.
| lenkite wrote:
| Also there is no "compiler" and "type checker" for your SPEC.
| If you get something wrong in some paragraph somewhere and or
| contradict something in your spec X paragraphs later - you have
| to use Mark-1 EyeBall to detect and fix this.
|
| You have just transformed your job from developer to manual
| spec maintainer - a clerk who has to painstakingly check
| everything.
| 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.
| orwin wrote:
| I agree, but i'm shouting at the cloud. Stuff needs to be
| done, it seems to work at first, so either i just abandon
| quality and let things rot, or i read everything and
| underline each time the code smell.
|
| I too use AI, but mostly to generate scripts (the most
| usefull use of AI is 100-200 line scripts imho), test
| _cases_ (i write the test itself, the data inside is
| generated) and HTML/CSS/JS shenanigans (the logic i code,
| the presentation i'm inferior to any random guy on the
| internet, so i might as well use an AI). I also use it for
| stuff that never end in repository, for exploration/proof
| of concept and outside of scope tests (i like to understand
| how stuff work, that helps), or to summarize Powerpoint
| presentations so i can do actual work during 60-person
| "meetings" and still get the point.
| whoisthemachine wrote:
| You don't have to. How else are the new hires going to learn
| the downsides of outputting so much unreadable BS?
| 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.
| chrisjj wrote:
| Joe should sue.
| exitb wrote:
| That'd be challenging for him right now.
| chrisjj wrote:
| Skip specs, and you often ended up writing the wrong program -
| at substantial cost.
|
| The main difference now is the parrots have reduced the cost of
| the wrong program to near zero, thereby eliminating much of the
| perceived value if a spec.
| 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.
| bigstrat2003 wrote:
| 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.
| 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.
| whynotminot wrote:
| Anyone who's been a developer for more than 10 minutes knows
| that best practices are hard to always follow through on when
| there's pressure to ship.
|
| But there's more time to do some of these other things if the
| actual coding time is trending toward zero.
|
| And the importance of it can go up with AI systems because they
| do actually use the documentation you write as part of their
| context! Direct visible value can lead people to finally take
| more seriously things that previously felt like luxuries they
| didn't have time for.
|
| Again if you've been a developer for more than 10 minutes,
| you've had the discouraging experience of pain-stakingly
| writing very good documentation only for it to be ignored by
| the next guy. This isn't how LLMs work. They read your docs.
| chrisjj wrote:
| > Anyone who's been a developer for more than 10 minutes
| knows that best practices are hard to always follow through
| on when there's pressure to ship. > But there's more time to
| do some of these other things if the actual coding time is
| trending toward zero.
|
| I think you'll find even less time - as "AI" drives the
| target time _to ship_ toward zero.
| whynotminot wrote:
| I agree that this will be the end result over time, maybe
| even faster than we expect. And as those speed pressures
| increase, AI will take over more and more of the
| development process.
| chrisjj wrote:
| These best practice protections become essential only when you
| give the work to _really_ bad programmers - such as parrots.
| 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_
| undeveloper wrote:
| small agents.md files are worth it, at least for holding some
| basic information (look at build.md to read how to build, the
| file structure looks like so), rather than have whatever burn
| double the amount of tokens searching for whatever anyways.
| 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.
| scherlock wrote:
| Same. Small units if work, iterate in it till it's right,
| commit it, push it, then do the next increment of work. It's
| how I've always worked like that, except now, I sometimes let
| someone else figure the exact API calls (I'm still learning
| react, but Claude helps get the basics in place for me). If the
| AI just keeps screwing up, I'll grab the wheel and do it
| myself. It sometimes helps me get things going, but it hasn't
| been a huge increase in productivity, but I'm not paying the
| bill so whatever.
| wreath wrote:
| so is the 10-20% in velocity worth the money and the process-
| complexity added? I'm assuming you're measuring your own
| velocity, not your team's, since that includes time to review
| and deploy etc.
| jwpapi wrote:
| The first rule is an antipattern. I think describing your
| architecture or ANY kind of documentation for your AI is an anti-
| pattern and blows the context window leading to worse results,
| and actual more deviation.
|
| The controlling systems are not give it more words at the start.
| Agentic coding needs to work in loop with dedicated context.
|
| You need to think about how can i give as much intent as possible
| with as little words.
|
| You can built a tremendous amount of custom lint rules ai never
| needs to read except they miss it.
|
| Every pattern in your repo gets repeated, repo will always win
| over documentation and when your repo is good structured you
| don't need to repeat this to AI
|
| It's like dev always has been, watch what has gone wrong and make
| sure the whole type or error can't happen again.
| andrekandre wrote:
| > repo will always win over documentation
|
| it really does seem like this... also new devs are like that
| too: "i just copied this pattern use over here and there whats
| wrong?" is something i've heard over and over lol
|
| i think languages that allow expression of "this is deprecated,
| use x instead" will be usefull for that too
| IhateAI wrote:
| How to write quality code with AI? Don't let it write the code.
| dwheeler wrote:
| I also made a list of tips on writing code with AI, with a
| special focus on security. Others may find the tips useful. Here
| they are: https://openssf.org/blog/2026/01/05/ai-software-
| development-...
| hannofcart wrote:
| 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 enforcement (via eslint)
|
| 5. Max file length enforcement (via eslint)
|
| 6. Unused code/export analyser (knip)
|
| 7. Code duplication analyser (jscpd)
|
| 8. Modularisation enforcement (dependency-cruiser)
|
| 9. Custom script to ensure shared/util directories are not over
| stuffed (built this using dependency-cruiser as a library rather
| than an exec)
|
| 10. Security check (semgrep)
|
| I stitch all the above in a single `pnpm check` command and
| defined an agent rule to run this before marking task as
| complete.
|
| Finally, I make sure `pnpm check` is run as part of a pre-commit
| hook to make sure that the agent has indeed addressed all the
| issues.
|
| This makes a dramatic improvement in code quality to the point
| where I'm able to jump in and manually modify the code easily
| when the LLM slot machine gets stuck every now and then.
|
| (Edit: added mention of pre-commit hook which I missed mention of
| in initial comment)
| Tade0 wrote:
| My setup has some of the things mentioned and I found that
| occasionally the LLM will lie that something passes, when it
| doesn't.
| hannofcart wrote:
| Yup I have run into the same.
|
| I use a pre-commit hook to run `pnpm check`. I missed
| mentioning it in the original comment. Your reply reminded me
| of it and I have now added it. Thanks.
| chrysoprace wrote:
| That's something I find to be incredibly frustrating. I
| have to keep reminding it that we're not done, no matter
| how much I enforce that the lints must pass before we're
| done.
| joquarky wrote:
| Make the error message much more dramatic and it will be less
| likely to miss it. Create a wrapper if you can't change the
| error message.
|
| Remember these are still fundamentally trained on human
| communication and Dale Carnegie had some good advice that
| also applies to language generators.
| esperent wrote:
| If you're using Claude try the hookify plugin and ask if to
| block commits unless the rules pass.
| ppoooNN wrote:
| 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.
| tiny-automates wrote:
| 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.
| esperent wrote:
| Except for dependency cruiser which I hadn't heard of, this is
| almost exactly what I've built up over the past few weeks.
|
| For the pre-commit hook, I assume you run it on just the files
| changed?
|
| > Custom script to ensure shared/util directories are not over
| stuffed (built this using dependency-cruiser as a library
| rather than an exec)
|
| Would you share this?
| altern8 wrote:
| Very nice.
|
| BUT, what is the point of max line length enforcement, just to
| see if there are crazy ternary operators going on?
| i5heu wrote:
| It makes diff split view nicer to use.
|
| At least this is the reason why I do use it
| b-karl wrote:
| Not a catch all to fix issues agree with linting. Being very
| strict with linters has become very cheap with coding agents
| and it keeps you up to date with code standards and keeps code
| style homogenous which is very nice when you are reviewing
| professional code, regardless of who wrote it.
|
| It's also tricky otherwise if you have to occasionally review
| lazily written manual code mixed with syntactically
| formal/clean but functionally incorrect AI code.
| clarity_hacker wrote:
| The forcing function doesn't disappear - it shifts. When you read
| and critique AI-generated code carefully, you get a similar
| cognitive workout: Why did it structure this that way? What edge
| case did it miss? How does this fit the broader architecture?
|
| The danger is treating the output as a black box. If you skip the
| review step and just accept whatever it produces, yes, you'll
| lose proficiency and accumulate debt. But if you stay engaged
| with the code, reading it as critically as you would a junior
| dev's PR, you maintain your understanding while moving faster.
|
| The technical debt concern is valid but it's a process problem,
| not an inherent flaw. We solved "juniors write bad code" with
| code review, linting, and CI. We can solve "LLMs write
| inconsistent code" with the same tools - hannofcart's 10-layer
| static analysis stack is a good example. The LLM lies about
| passing checks? Pre-commit hook catches it.
| teaearlgraycold wrote:
| Pre commit hook is definitely necessary. One thing I've seen a
| lot with Opus recently is it lying that a new linter warning or
| error was there before it made a change. They've learned from
| us too well!
| lz400 wrote:
| The best thing about this is that AI bots will read, train on and
| digest the million "how to write with AI" posts that are being
| written right now by some of the smartest coders in the world and
| the next gen AI will incorporate all of this, making them
| ironically unnecessary.
| klysm wrote:
| They will also be reading all of the slop generated by the
| current and previous generations of LLMs
| coldtea wrote:
| Each extra generation of AI produced crap AI consumes as
| training, the worse it gets. This has been mathematically
| proven.
| jatora wrote:
| Strange since, in practice, coding models have steadily
| improved without any backward movement every 3-4 months for 2
| years now. It's as if there are rigorous methods of filtering
| and curation applied when building your training data.
| coldtea wrote:
| > _Strange since, in practice, coding models have steadily
| improved without any backward movement every 3-4 months for
| 2 years now. It 's as if there are rigorous methods of
| filtering and curation applied when building your training
| data._
|
| It's as if what I wrote implies "all other things being
| equal", just like any technical claim.
|
| All other things were not equal: the architectures were
| tweaked, the human data set is still not exhausted, and
| more money and energy was thrown into their performance
| since it's a pre-IPO game with huge VC stakes.
|
| We've already seen a plateau non-the-less compared to the
| earlier release-over-release performance improvements. Even
| the "without any backward movement every 3-4 months for 2
| years now" is hardly arguable. Many saw a backward movement
| with GPT 4.1 vs 4.0, and similar issues with 4.5, for
| example. Even if those are isolated, they're hardly the 2
| to 3.5 to 4.0 gains.
|
| And no, there are absolutely no "rigorous methods of
| filtering and curation" that can separate the avalance of
| AI slop from useful human output - at least not without
| diminishing the possible training data. The problem after
| all is not just to tell AI from human with automated
| curation (that's already impossible), the problem is to
| have enough valuable new human output, which becomes near a
| losing game as all aspects of "human" domains previously
| useful as training input (from code to papers) are
| tarnished by AI output.
| kimixa wrote:
| None of this is _new_ , it was pretty much all "best practice"
| for decades and so already in the training data for the first
| generation.
|
| If the issue is SNR and the ratio of "good" vs "bad" practices
| in the input training corpus, I don't know if that's getting
| _better_.
| chrisjj wrote:
| > AI bots will read, train on and digest the million "how to
| write with AI" posts that are being written right now
|
| Yes!
|
| > by some of the smartest coders in the world
|
| Hmm... How will it filter out those by the dumbest coders in
| the world?
|
| Including those by parrots?
| ryanthedev wrote:
| I created my own Claude skill to enforce this and be sure it
| weaves in all the best practices we learned.
|
| https://github.com/ryanthedev/code-foundations
|
| I'm currently working on a checklist and profile based code
| review system.
| Sparkyte wrote:
| I use it for scaffolding and often correct it for the layour I
| prefer. Then I use to check my code, and then scaffold in some
| more modules. I then connect them together.
|
| Long as you review the code and correct it, it is no more
| different than using stackoverflow. A stack overflow that reads
| your code and helps stitch the context.
| anupamchugh wrote:
| "Stack Overflow that reads your codebase" -- perfect. But Stack
| Overflow is stateless. Agent sessions aren't.
|
| One session's scaffold assumes one pattern. Second session
| scaffold contradicts it. You reviewed both in isolation. Both
| looked fine. Neither knows about the other.
|
| Reviewing AI code per-session is like proofreading individual
| chapters of a novel nobody's reading front to back. Each
| chapter is fine. The plot makes no sense.
| elzbardico wrote:
| In general, I prefer to do the top-level design and the big
| abstractions myself. I care a lot about cohesion and coupling; I
| like to give a lot of thought to my interfaces.
|
| And in practice, I am happy enough that the LLM helps me to
| eliminate some toil, but I think you need to know when it is time
| to fold your cards, and leave the game. I prefer to fix small
| bugs in the generated code myself, than asking the agent, as it
| tends to go too far when fixing its own code.
| elzbardico wrote:
| Ironically, I use the time saved using agents to read technical
| books ferociously.
|
| Coding agents made me really get something back from the money I
| pay for my O'Reilly subscription.
|
| So, coding agents are making me a better engineer by giving me
| time to dive deeper into books instead of having to just read
| enough to do something that works under time pressure.
| Frannky wrote:
| I want to give a try to gsd + open code + Cerebras code. Any
| experience?
| theywillnvrknw wrote:
| TLDR: Know what you are doing and outsource the typing to LLM
| aristofun wrote:
| Why shallow and likely generated posts of a "Knowledge Management
| Advocate" get so many stars on hn?
|
| Just because of a hype?
| jatora wrote:
| Yes this is strange. There's nothing of substance here that
| hasn't been repeated many times before. BUT...I did click it
| out of interest. So maybe it just came at an opportune lull in
| these types of posts and during the inflection point of 4.6 and
| 5.3 release. Complete guess
| ewuhic wrote:
| AI slop article. Just show me the prompt.
| not_that_d wrote:
| The funny thing is, when I got a lead position in my job, I just
| to do real detailed ticket descriptions, going into technical
| considerations and possible cross domain problems. I did it for
| the juniors - and to be honest - for my self, since I know if I
| took that ticket, from that moment to the moment I put some code
| down I could just forget stuff.
|
| This was pushed back hard by management because it "took too much
| time to create a ticket". I fought it for some months but at the
| end I stopped and also really lose the ability and patience of do
| that. Juniors suffered, implementation took more time. Time
| passed.
|
| Now, I am supposed to do the exact same thing, but even better
| and for yesterday.
| aenis wrote:
| I'd add:
|
| Religiously, routinely refactor. After almost every feature I do
| a feature level code analysis and refactoring, and every few
| features - codebase wide code analysis and refactoring.
|
| I am quite happy with the resulting code - much less shameful
| than most things I've created in 40 years of being passionate
| about coding.
| perrygeo wrote:
| This. Historically there's been a lot of resistance to the idea
| of refactoring or refining features. The classic "It works,
| just ship it" mentality that leaves mountains of tech debt in
| its wake.
|
| And there _was_ a good reason to resist refactoring. It takes
| time and effort! After "finishing" something, the timeline, the
| mental and physical energy, the institutional support, is all
| dried up. Just ship it and move on.
|
| But LLMs change the equation. There's no reason to leave sloppy
| sub-optimal code around. If you see something, say something.
| Wholesale refactoring your PR is likely faster than running
| your test suite. Literally no excuses for bad code anymore.
|
| You'd think it didn't need to be said but, given we have a tool
| to make coding vastly more efficient, some people use that tool
| to improve quality rather than just pump out more quantity.
| mycall wrote:
| We are becoming spec writers, wearing the PM/lead hats.
|
| 1) Do a gap and needs assessment. 2) Build business
| requirements. 3) Define scope of work to advance fulfillment.
| 4) Create functional and non-functional specs. 5) Divide-
| conquer-refine loop.
| ebhn wrote:
| This is the main thing I have learned too. I've been building
| an internal tool for myself to annotate lines in each commit
| diff as good (green) / needs refactor (yellow) / needs rewrite
| (red) and it has helped me keep track of this kind of tech
| debt. Basically does what you could do with "TODO refactor"
| comments all over, but is more comprehensive and doesn't litter
| your source code. Plan to open source it once I've dog-fooded
| it a little more
| feastingonslop wrote:
| I don't understand the interest in "quality code." I never need
| to look at the code itself. I just make sure it runs right.
| acbart wrote:
| It makes it easier to make sure it runs right. Code that is
| easier to make sure is quality code. Code that is hard to make
| sure is not quality code.
| whoisthemachine wrote:
| What is the ratio of Markdown to Code with these agents? How
| readable is the Markdown after you've finished using it to
| develop your plan? How much time does it take to review code so
| closely vs. writing it yourself in the first place?
| toddmorrow wrote:
| [using an lmm as stack overflow]
|
| even if you check and redo after paste, you need to check for
| gotchas. I wish I had a nickel for every time the llm gave me a
| solution with a hidden limitation. assume that it violates all
| your unspoken assumptions, and adheres only to what you nailed
| down in your prompt
| gtirloni wrote:
| Spec-driven development is the only reliable way to work with AI.
| That's my current understanding. I spend more time refining the
| spec and bouncing ideas off of AI/team than before, which is good
| before there can't be any incorrect assumptions or hidden
| variables, otherwise AI will create suboptimal code. We should
| have been doing this much earlier in the process, even without
| AI, but now it's more necessary than ever. If you keep asking AI
| to make small changes as you learn about the business domain of
| your project, it will create a mess, in my experience. It's
| better to start from scratch and ask it to reimplement, if you
| finally understand all the requirements.
| jghn wrote:
| Sentiments like this make me wonder if perhaps the dream of the
| 90s was just ahead of its time. Things like UML, 4GLs, Rational
| were all being hyped. We were told that the future was a world
| where people could express the requirements & shape of the
| system, and the machines would do the rest.
|
| Clearly that didn't happen, and then agile took over from the
| more waterfall/specs based approaches, and the rest was
| history.
|
| But now we're entering a world where the state of the art is
| expressing your requirements & shape of the system. Perhaps
| this is just part of a broader pendulum swing, or perhaps the
| 1990s hopes & dreams finally caught up with technology.
| mpaepper wrote:
| Yes and no I'd say. It's still the case that now only by
| iterating and testing things with the AI you get closer to an
| actually good solution. So up front big spec will also not
| work so well. The only exception maybe if you already have a
| very clear understanding and existing tests (like what they
| did with the Claude's building the rust c compiler to compile
| the Linux kernel)
| air217 wrote:
| attention is all AI needs
___________________________________________________________________
(page generated 2026-02-07 23:01 UTC)