9 ms·

If you thought code writing speed was your problem you have bigger problems

• deleted 8mo ago
  [deleted]
• gammalost 8mo ago
  Seems easy to address with a simple rule. Push one PR; review one PR
  • hathawsh 8mo ago
    Also add a PR reviewer bot. Give it authority to reject the PR, but no authority to merge it. Let the AIs fight until the implementation AI and the reviewer AI come to an agreement. Also limit the number of rounds they're permitted to engage in, to avoid wasting resources. I haven't done this myself, but my naive brain thinks it's probably a good idea.
    • dmitrygr 8mo ago
      > I haven't done this myself, but my naive brain thinks it's probably a good idea. Many a disaster started this way
      • hathawsh 8mo ago
        Yep, we're on the same wavelength.
  • zer00eyz 8mo ago
    The problem is most of the people we have spent the last 20 years hiring are bad at code review. Do you think the leet code, brain teaser show me how smart you are and how much you can memorize is optimized to hire the people who can read code at speed and hold architecture (not code but systems) in their head? How many of your co-workers are set up and use a debugger to step through a change when looking at it? Most code review was bike shedding before we upped the volume. And from what I have seen it hasn't gotten better.
• deleted 8mo ago
  [deleted]
• luxuryballs 8mo ago
  It’s definitely going to create a lot of problems in orgs that already have an incomplete or understaffed dev pipeline, which happen to often be the ones where executive leadership is already disconnected and not aware of what the true bottlenecks are, which also happen to often be the ones that get hooked by vendor slide decks…
• furyofantares 8mo ago
  > The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in this example, weren't we? I often build something to figure out what I want, and that's only become more true the cheaper it is to build a prototype version of a thing. > You will build the wrong feature faster, ship it, watch it fail, and then do a retro where someone says "we need to talk to users more" and everyone nods solemnly and then absolutely nothing changes. I guess because we're just cynical.
  • zabzonk 8mo ago
    > Why can't faster typing help us understand the problem faster? Why can't standing on your head?
    • margalabargala 8mo ago
      Everyone has their own process.
  • bob1029 8mo ago
    > Why can't we figure out the right thing faster by building the wrong thing faster? Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time. This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.
    • furyofantares 8mo ago
      That's fair. I'm usually my own customer.
      • deleted 8mo ago
• gedy 8mo ago
  I'm cynical but kinda surprised that so many mgmt types are rah-rah AI as "we're waiting for engineering... sigh" has been a very convenient excuse for many projects and companies that I've seen over past 25 years.
  • shermantanktop 8mo ago
    Absolutely. Everyone loves a roadblock that someone else needs to clear, giving back some time to breathe and think about the problem a bit. This only works in large companies. In startups this is how you run out of money.
• everdrive 8mo ago
  Companies genuinely don't want good code. Individual teams just get measured by how many things they push around. An employee warning that something might not work very well is going to get reprimanded as "down in the weeds" or "too detail oriented," etc. I didn't understand this for a while, but internal actors inside of companies really just want to claim success.
  • mooreds 8mo ago
    > Companies genuinely don't want good code. I might be more charitable. I'd say something like "Companies genuinely want good code but weigh the benefits of good code (future flexibility, lower maintenance costs) against the costs (delayed deployment, fewer features)." Each company gets to make the tradeoffs they feel are appropriate. It's on technical people to explain why and risks, just like lawyers do for their area of expertise.
  • dannersy 8mo ago
    They don't care about good code, but they do pay people a lot of money to care about good code. If the people you hired didn't care, our software quality would be worse than it is. And since people are caring less in the face of AI, it is getting worse.
• myylogic 8mo ago
  [flagged]
  • devnotes77 8mo ago
    [flagged]
  • skydhash 8mo ago
    The thing is that speed in building stuff doesn't really help. What you want is a model and a simulation framework. In the traditional way, you usually start with a simple model and a simple framework. Then when you add a new parameter, you adapt the framework and once you've found a balanced set of inputs, you think which new parameter you want to add. This iteration leads to a great understanding of the model and the behavior of the system that implements it. LLM usage is usually a build of the system for the full parameter set. The speed increase is countered by the fact that there's no understanding of the system and the simulation space is so large that the user don't really bother to explore it. There's been a lot of talks about having a full test suite for simulation, but they are discrete and only prove specific points in the input space (There's a lot of curves that can pass through a finite set of points)
• 6stringmerc 8mo ago
  Because the way the world is currently and this is trending, let me jump in and save you a lot of time: Expedience is the enemy of quality. Want proof? Everyone as a result of “move fast and break things” from 5-10 years ago is a pile of malfunctioning trash. This is not up for debate. This is simply an observation. I do not make the rules. See my last submission for some CONSTRUCTIVE reading. Bye for now.
• petcat 8mo ago
  As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve. Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews. A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.
  • felipellrocha 8mo ago
    If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!
    • n4r9 8mo ago
      Can agents write good assembly code?
      • svachalek 8mo ago
        With the complexity of modern pipelines, there are very few humans that can beat a good optimizing compiler. Considering that with an LLM you're also bloating limited context with unsemantic instructions I can't see how this is anything but an exercise in failure.
        • mirsadm 8mo ago
          I don't know if I agree with that. It's a struggle to get a modern compiler to vectorize a basic loop.
• renewiltord 8mo ago
  Understanding the problem is easier for me experienced with engaging with solutions to the problem and seeing what form they fail in. LLMs allow me to concretize solutions so that pre-work simply becomes work. This allows me to search through the space of solutions more effectively.
• lukaslalinsky 8mo ago
  If I can offload the typing and building, I can spend more energy understanding the bigger picture
• devnotes77 8mo ago
  [flagged]
• devnotes77 8mo ago
  [flagged]
• danilocesar 8mo ago
  I'm here just for the comments...
  • deleted 8mo ago
    [deleted]
  • stronglikedan 8mo ago
    aren't we all...
  • antonvs 8mo ago
    These discussions remind me of two quotes: “This is just a moment in time. Step aside and let it happen.” - Inara Serra, Firefly. "Your effort to remain what you are is what limits you." Puppet Master, Ghost in the Shell.
• teaearlgraycold 8mo ago
  > I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks. The prospect didn't even end up buying. The feature got used by eleven people, and nine of them were internal QA. That's not a delivery problem. That's an "oh fuck, what are we even doing" problem. I have very much upset a CEO before by bursting his bubble with the fact that how fast you work is so much less important than what you are working on. Doing the wrong thing quickly has no value. Doing the right thing slowly makes you a 99th percentile contributor.
• phillipclapham 8mo ago
  [flagged]
  • _under_scores_ 8mo ago
    For me it's also in generating output that I know is right when I see it, but don't necessarily know every intricate detail of up front.
    • ohyoutravel 8mo ago
      You’re engaging with an LLM.
      • _under_scores_ 8mo ago
        Yes? Edit: you mean op?
        • ohyoutravel 8mo ago
          No I mean you. The person to whom you are responding is a bot. No judgment, just pointing this out in case you don’t want to waste human brain cycles.
          • _under_scores_ 8mo ago
            Oh! Whats the tell out of curiosity?
            • ohyoutravel 8mo ago
              This one in particular is a new account with a high volume of similarly-structured posts over an impossibly short time. Bigger tells are the other two green accounts posting multiple top level comments in this topic that are nearly identical. Perhaps the programmer had an off by one error somewhere. I count at least three top level posters, if not as many as five, in this topic that are LLMs.
• nathias 8mo ago
  people can have more than one problem
• podgorniy 8mo ago
  Yeah, we again have a solution (LLMs) in search of problems. Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z". -- This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..
  • raw_anon_1111 8mo ago
    This is categorically not true. For almost all of my 30 years it’s been 1. Talk to the business, solve XYProblems, deal with organization complexity, learn the business and there needs. 2. Design the architecture not just “the code”, the code has to run on something. 3. Get the design approve and agree on the holy trinity - time/cost/budget 4. Do the implementation 5. Test it for the known requirements 6. Get stakeholder approval or probably go back to #4 7. Move it into production 8. Maintenance. Out of all those, #4 is what I always considered the necessary grunt work and for the most part even before AI especially in enterprise development where most developers work has been being commoditized in over a decade. Even in BigTech and adjacent codez real gud will keep you as a mid level developer if you can’t handle the other steps and lead larger/more impactful/more ambiguous projects. As far as #5 much of that can and should be done with automated tests that can be written by AI and should be reviewed. Of course you need humans for UI and UX testing The LLMs can do a lot of the grunt work now.
    • zelphirkalt 8mo ago
      I see step 4 as interwoven with other steps. The implementation ideally takes into consideration the domain and while implementing, potentials for flexibility are potentially revealed, to be taken advantage of, "without programming ourselves into a corner". Implementation also is of course related to maintenance. Maintenance already needs to be taken into account. How easy is it to adapt the system we are building later? This all happens while we are at the implementation stage and impacts all other aspects of the whole thing. It is a grunt work, but we need elite grunts, who see more than just the minimal requirements.
• myylogic 8mo ago
  [flagged]
  • slopinthebag 8mo ago
    Ai generated comments are against the rules of HN. @dang this bot is spamming
• wolttam 8mo ago
  "Our newest model reduces your Mean Time To 'Oh, Fuck!' (MTTF) by 70%!"
• 725686 8mo ago
  The word typing is wrong. It is not about the speed of typing code. Its about the speed of "creating" code: the boilerplate code, the code patterns, the framework version specific code, etc.
• larsnystrom 8mo ago
  I can really relate to this. At the same time I’m not convinced cycle time always trumps throughput. Context switching is bad, and one solution to it is time boxing, which basically means there will be some wait time until the next box of time where the work is picked up. Doing time boxing properly lowers context switching, increases throughput but also increases latency (cycle time). It’s a trade-off. But of course maybe time boxing isn’t the best solution to the problem of context switching, maybe it’s possible to figure out a way to have the cookie and eat it. And maybe different circumstances require a different balance between latency and throughput.
• gyanchawdhary 8mo ago
  he’s treating “systems thinking” and architecting software like it’s some sacred, hard to automate layer that AI apparntly sucks at ..
• milesward 8mo ago
  Correct, but I'd frame it to confused leaders a bit differently. Because we made this part easier, we've increased how critical, how limiting, other steps/functions are. Data's more valuable now. QA is more valuable now. More teams need to shift more resources, faster.
• sorokod 8mo ago
  Amdahl's law applies regardless of whether you are believe in it or not
• avereveard 8mo ago
  Eh code doesn't have a lot of value. Especially filling methods between signatures and figuring out the dependencies exact incantation is mechanistic and definitely time better spent doing other things. A lot of these blog start from a false premise or a lack of imagination. In this case both the premise that coding isn't a bulk time waste (and yes llm can do debugging, so the other common remark still doesnt apply) is faulty and unsubstantiated (just measure the ratio of architects to developers) but also the fact that time saving on secondary activities dont translate in productivity is false, or at least it's reductive because you gain more time to spend on doing the bottlenecked activity.
• andrewstuart 8mo ago
  These “LLM programming ain’t nothing special” posts are becoming embarrassing for the authors who - due to their anti AI dogmatism - have no idea how truly incredibly fast and powerful it’s become. Please stop making fools of yourselves and go use Claude for a month before writing that “AI coding ain’t nothing special” post. Ignorance of what Claude can actually do means your arguments have no standing at all. “I hate it so much I’ll never use it, but I sure am expert enough on it to tell you what it can’t do, and that humans are faster and better.”
  • slopinthebag 8mo ago
    What makes you think they haven't? I agree with them and I've been heavily using Claude / Codex for a while now. And I'm slowly trying to use AI more selectively because of these concerns.
    • andrewstuart 8mo ago
      Ok tell me tangibly what you are programming, what you ask it to do and I’ll do similar and we can compare outcomes.
• cess11 8mo ago
  One of the main reasons I like vim is that it enables me to navigate code very fast, that the edits are also quick when I've decided on them is a nice convenience but not particularly important. Same goes for the terminal, I like that it allows me to use a large directory tree with many assorted file types as if it was a database. I.e. ad hoc, immediate access to search, filter, bulk edits and so on. This is why one of the first things I try to learn in a new language is how to shell out, so I can program against the OS environment through terminal tooling. Deciding what and how to edit is typically an important bottleneck, as are the feedback loops. It doesn't matter that I can generate a million lines of code, unless I can also with confidence say that they are good ones, i.e. they will make or save money if it is in a commercial organisation. Then the organisation also needs to be informed of what I do, it needs to give me feedback and have a sound basis to make decisions. Decision making is hard. This is why many bosses suck. They're bad at identifying what they need to make a good decision, and just can't help their underlings figure out how to supply it. I think most developers who have spent time in "BI" would recognise this, and a lot of the rest of us have been in worthless estimation meetings, retrospectives and whatnot where we ruminate a lot of useless information and watch other people do guesswork. A neat visualisation of what a system actually contains and how it works is likely of much bigger business value than code generated fast. It's not like big SaaS ERP consultancy shops have historically worried much about how quickly the application code is generated, they worry about the interfaces and correctness so that customers or their consultants can make adequate unambiguous decisions with as little friction as possible.
• metalrain 8mo ago
  I think it's more abstraction problem. You could write more code, but you also could abstract code more if you know what/how/why. This same idea abstracts to business, you can perform more service or you can try to provide more value with same amount of work.
• m463 8mo ago
  > The Goal ... it's also the most useful business book you'll ever read that's technically fiction factorio ... it's also the most useful engineering homework that's technically a game
• nicbou 8mo ago
  I'm a solo dev. In fact I'm hardly a dev; it's just a helpful skill. Code writing speed IS a problem, because it takes valuable time away from other tasks. A bit like doing the dishes. I just set up Claude Code tonight. I still read and understand every line, but I don't need to Google things, move things around and write tests myself. I state my low-level intent and it does the grunt work. I'm not going to 10x my productivity, but it'll free up some time. It's just a labour-saving technology, not a panacea. Just like a dishwasher.
  • rustystump 8mo ago
    This I think is pretty spot on. I still have to review the code ideally line by line. It is like templates, generators, etc. they help and do make things faster but 10x isnt gonna happen unless requirement gathering also 10x which so far, ai has had no impact on.
  • mooreds 8mo ago
    This is the way.
    • malfist 8mo ago
      [flagged]
  • apsurd 8mo ago
    The intention of the title is to say your main problem. The problem separating you from $PROFIT$: 1. Idea 2. ??? 3. Profit Coding effectively is definitely one problem. And you're right that AI helps with that problem. But for startups, side-hustles, VC-pitches and the inner-workings of companies (HN crowd) coding was never the problem. edit to add: So for people working on professional software teams, the discussion is how a hyper-increase in raw code production affects everything down stream. There are many moving parts to building stuff and selling it to people. So there's not a 1:1 line to more code = better outcome from the system level view. It's not clear, at least.
    • adwn 8mo ago
• bluegatty 8mo ago
  It's unfair to characterize AI as 'code writing / completion' - it's at minimum 1/4 layer of abstraction above that - and even just 'at that' - it's useful. So 'writing helper' + 'research helper' + 'task helper' alone is amazing and we are def beyond that. Even side features like 'do this experiment' where you can burn a ton of tokens to figure things out ... so valuable. These are cars in the age of horses, it's just a matter of properly characterizing the cars.
• mikkupikku 8mo ago
  My problem when writing code is mainly executive dysfunction; I constantly succumb to the temptation to take the easy way and do it properly later, and later never comes. For some reason, using a coding agent seems to alleviate this. Things get done the way I think they should be done, not just in a way that's "good enough for now."
• ianberdin 8mo ago
  I don’t agree. I have built Replit clone alone in months. They have hundreds of millions of funding… Btw: https://playcode.io https://playcode.io
  • deleted 8mo ago
    [deleted]
• bvirb 8mo ago
  When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time. So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet. We're finding cases where fast coding really does seem to be super helpful though: * Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out) * Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual) * Times where the path forward is simple but also a lot of work (tedious stuff) * Dealing with edge cases after building the happy path * EDIT: One more huge one I would add: anywhere where the thing you're adding is a complete analogy of another branch/PR the agent seems to do great at (which is like a "simple but tedious" case) The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced. I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).
  • webdood90 8mo ago
    > The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced Ugh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out. The human element in all of this never seems to be discussed. Maybe this will weed out those that are unworthy of the new process but I simply don't want to be "on" all the time. I don't want to be optimized like this.
    • whateverboat 8mo ago
      Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another. Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.
• slibhb 8mo ago
  The idea that LLMs don't significantly increase productivity has become ridiculous. You have to start questioning the psychology that's leading people to write stuff like this.
• k1rd 8mo ago
  > That's the part most people get. Here's the part they don't, and it's the part that should scare you: > When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one. if you ever played factorio this is pretty clear.
• myst 8mo ago
  No one there is solving a problem. The AI bros are hooking a new generation (NG) on _their_ set of crutches, without which NG "is not coding (living) up to their true potential". Nothing personal, just business. PS. The tech bros tried to do exactly that to millennials, but accidentally shot boomers instead.
• po1nt 8mo ago
  While reading articles like this, I feel like we're just in the "denial" stage. We're just trying to look for negatives instead of embracing that this is a definite paradigm shift in our craft.
• dannersy 8mo ago
  The blog isn't even necessarily anti-AI yet the majority of responses here are defending it like the author kicked their dog. The sentiment that developers shouldn't be writing code anymore means I cannot take you seriously. I see these tools fail on a daily basis and it is sad that everyone is willing to concede their agency.
• tmshapland 8mo ago
  Thank you. 100%.
• thepasch 8mo ago
  > Someone approves a PR they didn’t really read. We’ve all done it (don’t look at me like that). It merges. CI takes 45 minutes, fails on a flaky test, gets re-run, passes on the second attempt (the flaky test is fine, it’s always fine, until it isn’t and you’re debugging production at 2am on a Saturday in your underwear wondering where your life went wrong. Ask me how I know… actually, don’t). The deploy pipeline requires a manual approval from someone who’s in a meeting about meetings. The feature sits in staging for three days because nobody owns the “get it to production” step with any urgency. This is the company I (soon no longer) work at (anyone hiring?). The thing is that they don’t even allow the use of AI. I’ve been assured that the vast majority of the code was human-written. I have my doubts but the timeline does check out. Apart from that, this article uses a lot of words to completely miss the fact that (A) “use agents to generate code” and “optimize your processes” are not mutually exclusive things; (B) sometimes, for some tickets - particularly ones stakeholders like to slide in unrefined a week before the sprint ends - the code IS the bottleneck, and the sooner you can get the hell off of that trivial but code-heavy ticket, the sooner you can get back to spending time on the actual problems; and (C) doing all of this is a good idea completely regardless of whether you use LLMs or not; and anyone who doesn’t do any of it and thinks the solution is to just hire more devs will run into the exact same roadblocks.
• wei03288 8mo ago
  [dead]
• phyzome 8mo ago
  « you are speeding up the rate at which you build the wrong thing » Yeah. I keep seeing this over and over with devs who use LLMs. It's painful to watch.
• hintymad 8mo ago
  How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? When a person writes code, the person reasons out the code multiple times, step by step, so that they don't make at least stupid or obvious mistakes. This level of close examination is not covered in code review. And arguably this is why we can trust more on human-written code than AI-produced, even though AI can probably write better code at smaller scale. In contrast, Amazon asked senior engineers to review AI-generated code before merging them. But the purpose of code review was never about capturing all the bugs -- that is the job of test cases, right? Besides, the more senior an engineer is in Amazon, the more meetings they go to, and the less context they have about code. How can they be effective in code review?
  • giancarlostoro 8mo ago
    > How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? Right... Because Humans have never ever accidentally rm -rf'd a production system in the wrong spot? GitLab has entered the chat. Or that time an S3 developer purged more than intended, causing internet outages. All the above are from 2017. Then there was a deployment goof by Knight Capital Group, they lost 440 million in 45 minutes. The company went poof back in 2012 as a result. MySpace back in 2019 deleted a ton of prod data from users during a botched migration (oops). Humans make mistakes. Anyone arrogant enough to think they only write perfect code is delusional. We are holding AI to higher standards than we hold humans, who are just as fallible if not worse. QA your software, stop letting developers test changes.
    • hintymad 8mo ago
      I was not saying that humans are always right. I was assuming that humans probabilistically would make fewer obvious mistakes, which of course could be wrong and hence my questions. Speaking of QA, we would require AI to generate test cases, right? If so, do we rely on human review to ensure the quality of the test cases?
• ai-inquisitor 8mo ago
  This entire piece sounds AI written (or at minimum, heavily AI edited) with its "punchy" writing style LLMs love, negative parallelisms galore (see blockquotes 2, 3, 5), invented concept labels ("your calendar is a load-bearing wall" ???), attempts at humor sprinkled in. What a joke of a post.
• gitpusher 8mo ago
  > "When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one." > Think about it mechanically. If station A produces widgets faster but station B [...] cries in Factorio
• devonkelley 8mo ago
  [dead]
• amarant 8mo ago
  I think one of the biggest gains of AI is the second order effects. And maybe a bit in the third order as well. When coding with Claude, I can focus on the architecture, the big picture of the implementation, while Claude takes care of the details. Every function for which I don't have to remember the order of the arguments anymore, is a little bit extra brain power I can dedicate to thinking about the solution. I can focus on what matters, and I can focus for longer. I find that remembering argument order is much more tiresome than thinking through complex interactions(because the latter is fun, while the former is boring) Then there's the speedup. A smaller team can now achieve what a larger team was needed for before. This means less communication overhead, in theory fewer and/or shorter meetings. Which all translates to me spending more time and more energy on thinking about the solution. Which is what matters.
• babybjornborg 8mo ago
  I read this book last year and this application is spot on. There is a point in the narrative when the company automates a step in their manufacturing using an expensive machine and it has the effect developed here: the next step in the process is backed up further. The points specific to software where it might not even be producing in-spec is also very good. Comments that cite the solo dev/prototype case are of course not what this is getting at, but it's one good use of quick generation. I would extend this article by saying what The Goal says, namely that the goal of every firm is to make money, and everything is intermediate to that. So whether or not software architecture is grade-A or grade-C, it's only ever in this subservient role to the firm's goal.
• txrx0000 8mo ago
  Code-writing speed is not a bottleneck when the stakes are high. Sometimes, it's better to slow down, plan ahead, and consider the consequences because the cost of a failed iteration is too great. Take the way AI is being developed as an example. People rush to build giant agents in giant datacenters that are aligned to giant corporations and governments. They're building the agentic organism equivalent of machiavellian organizations, even though they'd be better off building digital humans that are aligned to individual humans that run on people's gaming PCs at home. They will find out that the former is the wrong architecture, but the cost of that failed iteration is the future of human civilization, and nobody gets a second try. Of course, this is an extreme example on one end of the scale. On the other end, it wouldn't matter at all if you're building a small game for yourself as a weekend project with no users to please or societal impacts to consider.
• brandensilva 8mo ago
  Ultimately the conclusion will be humans are the bottleneck somewhere along the path and no amount of agents will replace that person because you don't run businesses on vibes and code.
• 4ndrewl 8mo ago
  Tried this at numerous companies, small and large. The engineers get this, or are willing to learn. Some (by no means most) scrum/agile leads get it. The problem is the 'product class' don't get it, aren't interested and by-and-large don't have the aptitude to understand. Try tp explain cycle time, or cumulative flow diagrams to a Product Manage, Product Owner, Service Owner and they most often just brush it away as 'a technical thing' The problem only gets worse as the Peter principle begins to kick in and thin out the talent towards the top end of the org.
• twelvevaginas 8mo ago
  If LLMs didn’t forget everything ~500 lines ago I would be sipping Mai Tais. The lies about “agentic teams” and stacking GPUs in your apartment would come true. The only thing stopping a Jira board from self-implementing is context size limitations. Instead we have StackOverflow: Interactive Mode I disagree - if we really did have fully automatic task-to-PR that would basically solve it. Yeah sure you have product design and feature scoping this and that but the engineering problem is solved in the way the arithmetic problem is solved.
• agenticbtcio 8mo ago
  [dead]
• mfrankel 8mo ago
  The product world has a somewhat accepted idea to prototype to production framework. AI code generation is great in that world because there is a process to discover what problem to solve. System maintenance doesn't have a clearly defined "what problem to solve" path. Maybe it's smallest deployable increment to confirmed value delivery. But that's harder to systematize. And AI code generation is probably not a helpful tool here.
• pronik 8mo ago
  Code speed or not, people talk about how coding agents have taken away their passion. I've been reflecting on that for quite some time now and quite honestly, I don't miss a single thing. My passion has always been building something, but my building has always been hindered by a myriad of small paper cuts -- it's just what technology is and, if we are being honest, always has been. It's not being able to recall an exact syntax or a function name for something I know exists, it's frantically searching for whether something I need exists at all and if so, in anything I'm using alredy, it's a CI build not doing the simplest thing after working for months, it's a TypeScript error with a new library not wanting to compile until I change a dozen of things in tsconfig.json, it's my editor deciding not to update diagnostics today at any cost, it's deprecated syntax, it's documentation not describing what functions do and functions not working like the documentation describes them, it's hunting after weird bugs in fourth- and fifth-party code triggered exactly by four people in the world, one of them being me right now. This list goes on and on and all of those things are great when I finally manage to solve the problems. However, in terms of building things, I find it extremely liberating to have a literal assistant capable of sorting this shit out in seconds or minutes instead of me banging my head against the wall the whole night. Code writing speed wasn't my problem, but I appreciate when I can think about the code as the whole and change it as a whole in an instant. My time spent on building something hasn't changed much in absolute terms, but in the same spent time I will have taken a dozen detours, experimented with alternatives and provided enough context to tell anyone who asks why something is built this way and not another.
• Sammi 8mo ago
  This is actually an article about how small teams using ai vastly outperform large teams using ai. Because small teams don't have these coordination problems.