11 ms·
Lessons for Agentic Coding: What should we do when code is cheap?
- boesboes 5mo agoRealize it's going to be 10-100x more expensive once you have no way back?
- theshrike79 5mo agoWhat will close the way back?
- xandrius 5mo agoYou cutoff a generation of juniors from employment and learning , the seniors are gone and it's all harnesses and AI systems. I'm not all gloom and doom but the treatment of junior engineers is something I think we will either regret or rejoice. Either will have a spur of creative people doing their own independent thing or we'll have lost a generation of great engineers.
- orangecoffee 5mo agoThis is not happening at least for 25 years, is what seniors I trust tell me.
- GrinningFool 5mo agoI'd say closer to 10-15 but... I'm not sure the point you're making. Is it okay because it's 25 years in the future?
- lionkor 5mo agoIf we try hard enough, we can destroy the planet before we get there, I guess? 25 years is not a long time.
- est 5mo agoToday junior assembly language programmer are all gone, too.
- MagicMoonlight 5mo agoAnd that’s going to cause serious issues when people like Linus die and nobody knows how to make operating systems anymore. We’ve been coasting along on a single generation who have ruled with iron fists.
- fxtentacle 5mo agoYes and that’s why I can charge premium rates for debugging. Most people cannot read a stack trace anymore.
- ehnto 5mo agoLack of developers, if juniors don't get hired they will move onto other industries. Company brain drain, knowledge leaves with your seniors if you decide to get rid of them, or they just leave due to the conditions AI creates. I don't know if the above comes to fruition, there's a lot of questions that only time will answer. But those are my first thoughts.
- codebje 5mo agoBrain drain. If you fire all your SWEs they won't sit around twiddling their thumbs waiting for an AI collapse, they'll career shift. Maybe to an unemployment line and/or homelessness, maybe to something else productive, but either way they'll lose SWE skills. If you close down all the SWE junior positions you'll strongly discourage young people training in the field. They'll do something else. Then if you want to go back, who will you hire for it?
- nubg 5mo agoI agree with you, but it's a case of the tradegy of the commons. One single company cannot make a meaningful dent even with your insight.
- svantana 5mo agoWhy would anyone want to go back? It seems likely that the automated dev systems will just keep improving and get faster, cheaper, stronger.
- lionkor 5mo ago> automated dev systems They are large language models. Not automated development machines. They hallucinate. The goal post has not shifted since 2023 or so. Make an LLM that doesn't blatantly disregard knowledge it has, instructions it has been giving, over and over, and you win. If trillions of USD of investment can't do it, I'd be curious to see what can.
- svantana 5mo agoThere are definitely automated dev systems, of which an LLM is a part. The remaining part may be called a 'harness' or whatever. The quality of the generated software is another matter. If the AI is not good enough, then don't fire the devs. If/when the devs are no longer needed, I don't see why the need would return later, that was my point.
- HarHarVeryFunny 5mo ago
- amelius 5mo agoTime. In a few years there might be no old-school way to develop anymore. Everything will be built around AI.
- pjc50 5mo agoThe problem of "instant legacy" systems: something that's vibe coded and reached unmaintainable by either the AI or humans, but is also now indispensable because users are relying on it.
- tdeck 5mo agoI'm curious if this will cause a drop in quality that will lead users to generally lose trust in software.
- pjc50 5mo agoSome of that is already there .. but the users generally have nowhere else to go and ineffective pushback. "Enterprise software" has been awful for decades, things like Lotus Notes and SAP. Everyone hates Windows; everyone continues to use Windows.
- eloisius 5mo agoSee Windows 11
- GrinningFool 5mo agoUsers don't currently trust software. Look at what we've done to them - can you blame them? The consumer space is about extracting every ounce of personal data possible. The b2b space is about "maximizing customer value" - that is, not maximizing the value of your product to the customer, but maximizing the value of the customer to your business. Lock them in and lock them down, make your product "sticky" so they can't leave without immense cost.
- HarHarVeryFunny 5mo agoThere will always be competition. For every company negatively impacting customer experience and their own ability to compete, there will be others happy to step in and take advantage of that.
- varjag 5mo agoHey you can just rewrite (or should we say regenerate) it. Second system has never been cheaper!
- FeepingCreature 5mo agoThere is no moat. https://newsletter.semianalysis.com/p/google-we-have-no-moat-and-neither https://newsletter.semianalysis.com/p/google-we-have-no-moat...
- livinglist 5mo agoThe article is from 2023, I’m wondering if things mentioned still stand true today, can someone pls let me know.
- raincole 5mo agoIt's much truer today. You can say that article is extremely insightful, as it predicted today's open weighted models scenario 2 years earlier.
- energy123 5mo agoIt remains an unproven hypothesis. The revenue of the top 2-3 labs is still growing nearly exponentially, which is the ultimate piece of data that settles the question empirically for now. Benchmark scores aren't really proof. Benchmaxxing is possible, for example. Only revenue numbers (and gross margins) count.
- quikoa 5mo agoThe ultimate piece is not revenue but profit. At some point these enormous investments will have to be earned back. Good luck with that when open weight models are also continuously improving, have cheap providers and for many are already very usable.
- DrScientist 5mo agoThe other point to make is that companies are starting to worry about the risks of externally hosted models. This is at multiple levels if you have a remote API call as a key part of your workflow/software system. 1. Price risk - might be affordable today - but what about tomorrow? 2. Geopolitical risk - your access might be a victim of geopolitics ( seems much more likely that it used to be ). 3. Model stability/change management - you've got something working at the API get's 'upgraded' and your thing no longer works. If you are running on open weight models - you are potentially fully in control - ( even if you pay somebody to host - you'd expected there to be multiple hosting options - with the ultimate fallback of being able to host yourself ).
- user34283 5mo agoHow do you reconcile these ideas with the fact that cheap open weight models are only slightly behind the state of the art? If anything, I would bet that next year you could get today’s flagship performance for significantly cheaper via an open-weights model.
- LurusCode 5mo agoYou can easily develop with models like GLM 5.1 and Kimi k2.6 at a fraction of the cost of GPT 5.5 or Opus 4.7. Requests often cost just a few cents. Open-source models have caught up tremendously recently. Those who can’t or don’t want to invest a lot of money can already develop with Kimi and GLM without any problems. We don’t have to wait another year for that.
- GrinningFool 5mo agoTried deepseek 4 w/ CC yesterday, and was watch my usage eke up by only 0.01 at a time while doing plenty of high-token-count tasks. I understand it's currently at a discount, but even after that expires the same-quality output will be available at a fraction of the cost of the expensive models. From experience, the same level of usage would have left me stranded on my CC 5 hr limit within an hour. There were some difficulties with tool calls, in particular with replacing tab-indented strings - but taking no steps to mitigate that (which meant the model had to figure it out every time I cleared context) only cost relatively few extra tokens -- and it still came in well under 4.6, nevermind 4.7. And of course, I can add instructions to prevent churning on those issues. I have no reason to go back to anthropic models with these results. "No moat" indeed.
- wartywhoa23 5mo agoSure, but there will always be some monstrosities like Mythos that'll pwn all software written by local models in 0.01 seconds, thus forcing people/companies to use the most advanced paid models to keep up and stay unpwned for 1 second longer. (Timeframes are hyperbolical).
- duskdozer 5mo agoBy that time, the hypebeasts will be explaining how worthless the models of today always were.
- schnitzelstoat 5mo agoI've found the get-shit-done tool[1] to be quite useful for forcing me to properly plan the implementation and ensuring the context remains small and relevant at all times. It is slower than when I was just using Claude directly though. [1] https://github.com/gsd-build/get-shit-done https://github.com/gsd-build/get-shit-done
- justech 5mo agoI've tried this, it's honestly not worth the amount of time (and additional context) for the results. I've had more success prompting Claude with manageable and testable iterations. Planning is good but get-shit-done just added too much planning in my opinion.
- schnitzelstoat 5mo agoIt seems there is a new version [1] - I'll try it out and see if it is better. [1] https://github.com/gsd-build/gsd-2 https://github.com/gsd-build/gsd-2
- faangguyindia 5mo agoI am in India, junior developer hiring is all down. Ai has reduced offshoring to India and eliminated the need for janitor work (often offloaded to juniors). Many people are finding it difficult to even land internships. The most affected areas are sysadmin, devops, and frontend. Where you'll have very hard time getting any offer. Companies like BrowserStack are withdrawing campus placement offers. Meanwhile, I am writing apps for my own use and have reached 10,000+ monthly active users already, even though I am making zero money from doing all this, but it's fun.
- consp 5mo agoLooking at the entire market in Europe it is also down but that is not due to "AI" but because they are easiest to fire with least consequences. There is a global recession looming, despite Wall Street saying otherwise.
- satvikpendem 5mo agoEurope is easiest to fire? I would've thought the opposite.
- fernandotakai 5mo agodepends on the country, i would guess. but firing because "ai makes us more productive" is basically impossible in most eu countries.
- aspectrr 5mo agoI'm surprised sys-admin hires are down, is AI doing a lot of that as well?
- rirze 5mo agoYah, that comment is odd. Sysadmins, Devops engineers will the be the last ones replaced by AI. The context window for their problems are huge. Unless you define Sysadmins and Devops as fiddling with YAML all day, which might be the case here.
- torben-friis 5mo agoI came here exactly to point out what I'm glad to see is 10. "Free as in puppies" is a wonderful way to put it. Every time I open linkedin I'm scared of how many big heads have taken the wrong lesson that coding almost free == free engineering. So many bait posts asking engineers why they would need to pay them any longer, or being glad they're generating millions of lines a month....this is going to end badly.
- scorpioxy 5mo agoI had a business owner tell me that they don't need to hire juniors anymore because claude can do all of that work for them. This was not a software shop so it's not even about writing code but I also thought that was something that will bite in the near future. A business that is not investing in juniors is a business that is not investing in the future.
- pjc50 5mo agoThe role of AI in non-software shops is going to be interesting. To a great extent it's not competing with devs, it's competing with Excel. However bad a system your AI can produce, it can't compare to the workflows that a group of non-techies armed only with Office can produce. On the other hand, like giving a supercar to a teenager, this just enables them to get into trouble faster. (the "my vibe coded app deleted prod!" stories are funny schadenfreude when they happen to SV startups, whose whole business is pretending to know better. When this happens to a small business who've suddenly lost all their finanacials and now maybe will lose their house, it's a tragedy. And this can happen on a much larger, not AI-related scale, like Jaguar Land Rover: https://www.bbc.co.uk/news/articles/cy9pdld4y81o https://www.bbc.co.uk/news/articles/cy9pdld4y81o )
- duskdozer 5mo ago[dead]
- chasd00 5mo ago> The role of AI in non-software shops is going to be interesting I have friend in west Texas who does industrial electrical gear sales (like those giant spools of cable you see on tractor trailers). He’s 110% good old boy Texan but has adopted and loves AI. He says it’s been a huge help pulling quotes together and other tasks. Coincidentally he lives in Abilene where one of the stargate campuses are going. Btw, the scale of what’s being built in Abilene is like nothing I’ve ever seen.
- pjc50 5mo agoApart from (2), the first seven lessons are exactly identical to good project management practices with humans. Which are also the difficult bits. Once upon a time, highly bureaucratic organizations tried to make a distinction between "analyst", "programmer" and "coder": https://cacm.acm.org/opinion/the-myth-of-the-coder/ https://cacm.acm.org/opinion/the-myth-of-the-coder/ The pure "coder" role, per that paper, died out almost immediately. Nowadays it's done by compilers (a deterministic automation). The distinction between analyst and programmer held out a bit longer - ten years ago I was working somewhere that had "business analysts", essentially requirements-wranglers. It's possible that the "programmer" job of converting a well-defined specification into a program is also going to start disappearing. .. but that still leaves the specification as the difficult bit! It remains like the old stories with genies: the genie can give you what you ask for. But you need to be very sure what you want, very clear about it, and aware that it may come with unasked-for downsides if you're not.
- tommy29tmar 5mo ago[flagged]
- vicchenai 5mo ago[flagged]
- utopiah 5mo agoThis is such a weird argument, beside obvious #10 which will bite back with a vengeance, because... code can't be cheaper than free! Since at least the early 80s a LOT of very important code wasn't cheap, it was free. Both free of cost (you could "just" download it and run it) but also free as freedom-respecting software. I just don't get the argument that cheap is new. Cheap is MORE expensive than free!
- andai 5mo agoRe: personalized software via vibe coding Free but you're responsible for maintaining it means it's not free. It's the same issue as maintaining your own fork. It's just an ongoing cost. (Though as AI becomes autonomous enough to be the maintainer, that cost kind of goes away. Then it's just the cost of managing the "dev".)
- utopiah 5mo agoRelated recent discussion https://news.ycombinator.com/item?id=48005809 https://news.ycombinator.com/item?id=48005809 including distinction between your/our software
- noelwelsh 5mo agoCertain types of code are cheap. Proof of concept is cheap. Adding small features that fit within the existing architecture is cheap. Otherwise, I'm not so sure. Coding agents are fantastic at minutiae, but have no taste. They'll turn a code base into a ball of mud very quickly, given the opportunity.
- pell 5mo agoWhile I agree with you that agentic coding still has quite a way to go and is not always producing the quality that I would want from it, I can say quite confidently that its baseline is way above some of the production code in many applications many people use today. It really isn’t that code before agents was primarily written with taste and beautiful structure in mind. Your average code base is a messy hell full of quick fixes that turned into all kinds of debt over the years.
- noelwelsh 5mo agoI agree. I do wonder if what I'm seeing is a limitation of the reasoning power of LLMs or if it's just replicating the patterns (or lack thereof) in the training data.
- DrScientist 5mo agoIndeed. On github I wonder what the proportion is between well engineered big systems versus throw away/student projects. Even for the well engineered stuff I suspect there is a strong bias towards standalone projects versus larger multi-component systems.
- jmull 5mo agoI took the previous post, with its mention of the ball of mud, to be about complexity. “Taste”, is used in many cases, I suspect, to give a name the collection of practices and strategies developers use to keep their code and projects at a manageable level of complexity. LLMs don’t seem to manage complexity. They’ll just blow right past manageable and keep on going. That’s a problem. The human has to stay in the loop because LLMs only build what we tell them to build (so far). BTW, the essay that introduced the big ball of mud pattern to me didn’t hold it up as something entirely bad to be avoided. It pointed out how many projects — successful or at least on-going projects — use it, and how its passive flexibility might actually be an advantage. Big ball of mud might just be the steady state where progress can be made while leaving complexity manageable.
- DeathArrow 5mo ago>What should we do when code is cheap? Buy in bulk and resell. /s
- gitgud 5mo agoIt's cheap to change code, it doesn't mean you have to add more of it...
- remify 5mo agoCode might be cheaper but it's still a liability. In that regard anything that's not been properly designed and documented is going to be an even bigger issue.
- neowalter 5mo ago[flagged]
- jmull 5mo agoI think you can boil down most of the list to: Understand what you want to do. I’m not convinced about rebuilding repeatedly as a learning tool though. As relatively quick as it is, it over emphasizes the front line problems you face early. Those tend to be simpler, more straightforward issues that can be more quickly solved by a few minutes of thought (and more cheaply too).
- cermicelli 5mo agoLearn to throw code away
- azyc 5mo agoStick to patterns which were painful before. For example, I recently refactored a project written in TS to use better-result instead of throwing errors. Without Claude writing out all of that boilerplate I could not have imagined transitioning to this. Right now the cost of "doing it right" is decreased so much there is no reason to ship slop / poorly thought out code.
- asG1298 5mo agoGuy works for the Overture Map Foundation, with Amazon, Microsoft etc. being sponsors. He has been boosting AI all over the Internet. I'm sure Microslop and Amazon are very happy with these efforts. I'm glad that "10 ways to do X" submissions are allowed as long as they boost AI.
- simonw 5mo agoAre you suggesting that Microsoft and Amazon's sponsorship of Overture comes with an understanding that people who work on Overture will spend their time writing articles that "boost AI"? Does "boosting AI" include opening an article with "Frontier models are really good at coding these days, much better than they are at other tasks"?
- 16bitvoid 5mo agoCan't speak for the former, but the latter question: yes. "Product is really good at X, much better than at Y" does not imply that it's bad at Y, and even if it did, if you're targeting an audience that only cares about X, who gives a shit about Y? Might as well throw Y under the bus to boost the perceived effectiveness of product at X even more in comparison.
- miltonlost 5mo agoHow is that not boosting AI? It's certainly not denigrating it
- simonw 5mo agoI read it as mild denigration, because the AI companies would very much like you to believe that agentic AI works great for everything beyond code.
- melvinroest 5mo ago> What should we do when code is cheap? Make usable software. Cheap code means that you can create a lot more prototypes to then perform usability tests by finding a user and sitting next to them. I mostly worked on internal apps lately, so perhaps it's much easier for me to do than it is for some others.
- spicyusername 5mo agoA lot of people down on AI in this thread, but I'm watching the industry slip over the line of trust with these latest frontier models. GPT 5.5 is the first model good enough for me to just let rip. Every jira ticket I see now has acceptance criteria, reproduction steps, and detailed information about why the ticket exists. Every commit message now matches the repo style, and has detailed information about what's contained in the commit. Every MR now has detailed information about what's being merged. Every code base in the teams around me now has 70 to 90%+ code coverage. Every line of code now comes with best practices baked in, helpful comments, and optimized hot paths. I regularly ship four features at a time now across multiple projects. The MCP has now automated away all of the drudgery of programming, from summarizing emails, to generating confluence documentation, to generating slide decks. People keep screaming that tech debt is going to pile up, but I think it's going to be exactly the opposite. Software is going to pile up because developing it is now cheap. Most code before llms sucked. Most projects I on-boarded to were a massive ball of undocumented spaghetti, written by humans. The floor has been raised significantly as to what bad code can even look like, and fixing issues is now basically free if your company is willing to shell out for tokens.
- mhitza 5mo ago> GPT 5.5 is the first model good enough for me to just let rip. You know this is the exact same thing said during Opus 4.6, right? That makes it hard to believe because it's the same "last week's model was so much behind you can't even comprehend" meme that's been going on throughout last year. More info dumped into tickets and projects is great for understanding for both people and LLM. But hopefully not LLM generated.
- kusokurae 5mo agoIt's just cope. I'm so close to just never coming back to HN because the quality of thought has just gone through the floor. Anything whatsoever to hedge one's way to fellating a phallusless chatbot
- john_strinlai 5mo ago>You know this is the exact same thing said during Opus 4.6, right? spicyusername said this exact same thing about Opus 4.6? or is there more than one person on HN, and perhaps they have different opinions?
- lionkor 5mo agoIf writing code was the only part of the job, and it was easy, these jobs wouldn't pay so well. Engineering is hard. It's always going to be hard. I'm glad that AI makes some parts of it easier, and we (software engineers) can focus on engineering, that's nice. Code is NEVER cheap. Just because, at current completely unrealistic AI pricing, using agents is cheaper than hiring juniors, does not make code cheap. It makes producing code cheap, which has always been low-cost. Every line of code is a cost, is a maintenance burden, is complexity. An AI, even with somehow infinite context window, will cost more money the more code you have. Could you replace a whole team of engineers with AI? Probably, yeah. Could you simply fire everyone at your company and close it down, without much of a problem? Also probably yes, for most companies. AIs can help with debugging, can help with writing code, with drafting designs, they can help with almost every step. The second you let OpenAI, or Anthropic, take full code ownership over your products, and you fire the last engineer, is the time when the AI pricing can go up to match what engineers make today. You've just reinvented the highly paid consultant. Or you could take the middle-ground and hire good engineers, make sure they maintain an understanding of the codebase, and let them use whatever tools they use to get the job done, and done well. This is the way that I've seen competent companies handle it.
- peab 5mo ago"Producing code has always been low cost" Relative to what? I don't understand people dismissing the massive decrease in both cost of producing code and the speed of producing code. Before AI, people running businesses had similar issued as people have with AI now, but the costs were much greater. They could hire someone to write them a prototype for their idea, but it would cost them on the order of 1000s of dollars, and it would take weeks at the minimum! Now it could cost them 20$ and be done in a few days. The feedback loop is the bottleneck.
- isaacaggrey 5mo agoI understood it in the spirit of “code is a liability not an asset.” Code still needs to be maintained, changed, etc whether that is by a human or LLM. In other words, just because more code can be produced quickly does not mean that it is cheap. edit: I’m maybe hearing your point is that LLMs may change that POV but I think that is TBD.
- j45 5mo agoPeople should do what has always been needed, rather than focus on how hard it is to build something, or easy, find what is needed, what right is, what good is, what quality is that actually solves problems and do those things.
- luodaint 5mo ago#10 needs more emphasis than it receives. Cheaper code doesn't automatically lead to good product decisions. Instead of focusing on whether you can build it, the scarcer resource becomes whether you should build it. And most teams lack a clear process for addressing this latter question. Requirements are collected in all sorts of places without ever being prioritized in an organized fashion. This is exacerbated by cheaper code. With cheaper code, you can release five times what you used to be able to release in a given period of time, but only if you knew which five products you needed.
- jackcviers3 5mo agoFor most teams, whether or not you can say no to building something is ambiguous at best, at least if you wish to stay on that team and at that company. It's definitely one of the things that has made me vote with my feet in the past. With agentic coding, the ability to say no is pretty much gone because the perception is that it's just one more parallel thing we can throw an agent at. The thing I see from agentic adoption that I find lamentable as a software engineer is that timeline expectations have collapsed to absurdity. You can plan a project to do a major migration, do all the estimations on how long something will take, and if you give an answer that says weeks and cite the evidence, product and leadership will now claim it should take days, citing their ai's design. It's exhausting. Even if you are an expert, you now have lost the implicit trust that came from years of building political capital, shipping efficiently, and delivering value for multiple companies, because a different prompt with different context from the one you provide gave a different answer than what you did. During delivery, if you read your code produced line-by-line and review for correctness, and put in additional guardrail automations that slow the automated build, and ship 4 times a day with a defect rate of 5.4% with agentic coding, you are compared unfavorably to teams with a change defect rate of 15.7% that ship 13 times per day, because you are too slow. And you are individually compared with whole team outputs. Even if you deliver at a rate ten times greater than the worst contributor at your company, if you are not outputting code at the rate of an entire team of 5, you are not meeting the expectations of product and leadership anymore. All of this is to say, yes, people are looking at software engineers as both the bottleneck and unnecessary, even at high technology companies, right now. They are looking at them that way because they have their own agents that are biased to think that the engineering claims are wrong and agents are sycophantic.
- hansmayer 5mo ago"We" should not do anything. The LLM industry should go and find solutions for the problems they created, themselves. Not offload it to others through sneaky influencer posts. And we should hold them responsible, should they not be able to address the problems they are creating.
- vorsken 5mo ago[flagged]
- __mharrison__ 5mo agoWould add my biggest tip to that: TDD. Most people omit it. There is a difference between: - write code, write tests And - write tests, write code Had another agentic (vibe) coding experience, which confirmed that for me. Creating an SDK for a $500 light so I can control it from my Steam Deck instead of my phone (no SDK existed before yesterday). For anyone interested, I'm teaching my vibe coding (I meant agentic) tutorial at pycon next week. The 3-hour-long version should be posted to YouTube soon thereafter.
- kushalpatil07 5mo ago[flagged]
- storus 5mo agoI used to work as a VP and a part of my responsibilities was to chop up tasks to self-contained work units that can be easily assigned to random devs. This was both morally problematic for humans (i.e. EVPs forced treating human = CPU) and very optimistic when it came to individual dev capabilities and domain knowledge. However, this style is precisely what works well with agentic AI coding and I have no qualms to use it.
- jerf 5mo agoWe change how we value code: https://jerf.org/iri/post/2026/what_value_code_in_ai_era/ https://jerf.org/iri/post/2026/what_value_code_in_ai_era/ Short-short version, code will still be accruing value in proportion to how much of the real world it has encountered. The bottleneck on building valuable code will be how much real world there is to go around. As is so often the case, what may initially seem to kill SaaS will actually make them stronger as they end up with more exposure to the real world than some random guy's random AI code.
- tuo-lei 5mo ago[dead]
- KevinMS 5mo agoIs it cheap though? Do we actually know how much it costs? Isn't it possible that TODO app you vibe coded in 15 minutes actually costs investors $50k?
- ua709 5mo agoNot all code is cheap. Some code remains very expensive. But the idea that some code is cheap and some code is expensive is not new. The only new thing is there are some adjustments on how to asses the value of the code you’re presently, or about to, work on. AI has absolutely expanded the set of code that is cheap and if you can make a thing easily with AI then so can someone else. That project is unlikely to result in valuable code. Which is not to say it doesn’t have utility. Just its monetary value is low.
- beepbooptheory 5mo ago> Automate everything thats easy. Hold on, I better write this down, this is good stuff..
- nelfrancis 5mo ago[dead]
- jimmypk 5mo ago[flagged]
- jedahan 5mo agoCode is a liability - the more there is, the higher potential for bugs and poor performance. I'd recommend treating cheap code like cheap toxic waste, and try to minimize how much is generated.
- conorliu 5mo ago[dead]
- SKILNER 5mo agoDisappointing - not a very insightful list
- dzonga 5mo agothe best code is the code you never have to write. this means code also written by 'A.i'. seems as an industry we're hellbent on optimizing for the wrong-thing.
- maxothex 5mo ago[flagged]
- fithisux 5mo agoFinish unmaintained Open Source OSes?
- brcmthrowaway 5mo agoEvery thread on this topic has so much authoritative pontification. In the end, it doesn't really matter what some $random internet person thinks.
- 2001zhaozhao 5mo agoGood list, I have intuitively realized all of these except for (3). I agree with the author: cheap experiments to figure out a grand architectural plan, then executing fast without needing to wait for input is the right way to go. "Automate everything that's easy" is also important, but I'd extend it and say you probably should try to automate things that are hard too: it's worth spending a great deal of time on it simply due to how crazy valuable the returns are. But I guess I should look more into end-to-end testing.
- w10-1 5mo agoIt's not a question of cheap or expensive; it's when to pay what costs. With LLM's, it's arguably easier to avoid exporting costs to the future, or to export them. Whether because of LLM's or frameworks, process consistency typically creates a forcing function to continuously improve quality (i.e., avoid exporting costs); for each problem, create step in the process to surface and address it - hopefully in an automated way. Having spent lifetimes trying to get teams to up their game, I'm hopeful this may help, if it gets baked in not just to code generation, but to process.
- ori_b 5mo agoLessons for agentic swimming: What should we do when lead weights are cheap? Also: > It’s invigorating, rewarding, and deeply weird. It's mind-numbing, infanialising, and deeply dehumanizing. Which, I suppose, is a valid description of the future silicon valley is building. The remainder of the post is as vapid as the AI generating it.
- Bmello11 5mo ago[dead]
- noashavit 5mo agoI think there is a massive divide in the market between large enterprises and smaller org. The large enterprises are their typically laggard self. Prioritizing governance over innovation. Everyone else, at least in tech or tech adjacent, is building. Build vs buy is the conversation.
- theuniverseson 5mo ago[flagged]
- nike-17 5mo ago[flagged]
- deferredgrant 5mo ago[flagged]
- lacymorrow 5mo ago[flagged]
- NortySpock 5mo agoWrong answers: $1 Plausible answers: $10 Good, useful answers: $100 Validation and Verification is what separate "should work" from "is shown to work". Anyone can write non-functional code. It's functional useful code that takes more work.
- whatever1 5mo agoStop spending time on design. Try all of the permutations and stress test them. Stop caring about extendable modular code. Just rewrite from scratch when you have new requirements. Build a demo for every idea you have. Build 100 visualizations and metrics for any algorithm you develop. We are finally free of friction. Bad news is we have no brakes. Brace for impact.
- conor- 5mo ago> We are finally free of friction Free from friction, constrained by pricing and a massive ladder that can be pulled up by companies that are in no way benevolent. If you're one of the lucky few who were able to already have hardware that can run some of the open weight models you can be a beneficiary for now - but that won't last forever.
- mrothroc 5mo agoThe list in the article looks like verification practices. Document intent, develop taste, find the hard stuff, etc. It assumes that when code is cheap the bottleneck shifts to knowing whether what you generated is actually right. e2e tests can do a lot, but in my experience it's not enough. By the time the test fails you've already burned a generation cycle on an artifact that came from a flawed spec or design. I've gotten more mileage from having checks at stage boundaries (standard SDLC: plan, design, code, test). We all know the earlier you catch the mistake, the cheaper the fix. The "implement to learn" is the same idea: you need to know enough about both where you want to go AND the path to get there to guide the agents to a proper implementation. You have contact with the world, both the users and the operational considerations that come from running software. Agents do not. We do the same thing with spikes, but now our spikes become far more sophisticated. Code being cheap doesn't remove verification, it moves it earlier.
- chermi 5mo agoI find the intent/why very important. I have a rule in vault related that basically anytime CC writes a WHAT (requirement, concept, RFC) it must colocated a WHY and the WHY should be MY words. It helps resolve a lot of confusion.
- hulitu 5mo agoTest it for god's sake. Test it.