18 ms·

Writing Code Was Never the Bottleneck

• 5350-uiop-1130 1y ago
  bottom line is only thing that matters in the end
• cies 1y ago
  Funny article, but it seems that the author did not get the "Definition of Done" memo. While... > Writing Code Was Never the Bottleneck ...it was also never the job that needed to get done. We wanted to put well working functionality in the hands of users, in an extendible way (so we could add more features later without too much hassle). If lines of code were the metric of success (like "deal value" is for sales) we would incentivize developers for lines of code written.
  • weego 1y ago
    We used to. Then we went though a phase of 'rockstar' developers who would spend their time on the fledgling social media sites musing on how their real value was measured in lines of code removed.
  • ctenb 1y ago
    This article nowhere suggests that lines of code is something to be maximized.
  • lmm 1y ago
    > We wanted to put well working functionality in the hands of users, in an extendible way (so we could add more features later without too much hassle). I think the author agrees, and is arguing that LLMs don't help with that.
  • deleted 1y ago
    [deleted]
• virgilp 1y ago
  TBH, I feel like the biggest help Cursor gives me is with understanding large-ish legacy codebases. It's an excellent (& active) "rubber duck". So I'm not sure the argument holds - LLMs don't just write code.
  • gabrielso 1y ago
    I'm not having the same positive experience on a >25yo insanely large and codebase built with questionable engineering practices
  • octo888 1y ago
    Or is it just giving you a limited understanding but pretending it's grokked the entire codebase AND data?
    • zeroCalories 1y ago
      Yeah I've run several SOTA tools on our gnarly legacy codebase(because I desperately need help), and the results are very disappointing. I think you can only evaluate how well a tool understands a codebase if you already know it well enough to not need it. This makes me hesitant to use it in any situation where I do need it.
    • virgilp 1y ago
      But that's already way better than a physical rubber duck. That was my point.
• IshKebab 1y ago
  Was anyone claiming it is the bottleneck? Seems like a straw man.
  • raffael_de 1y ago
    I have seen it being claimed many times; especially here on hn. Context is usually optimized coding experience with respect to keyboard options and editors (vim/emacs vs modern IDEs).
  • gwervc 1y ago
    A few weeks ago people were discussing here how their typing speed was making them code faster. On the other hand I haven't been limited by writing code, the linked article match my professional experience.
    • Xss3 1y ago
      You have to be fluent on the keyboard, to type without thought or 'hunting and pecking' if you want your ideas to flow from brain to pc smoothly and uninterrupted. Speed is part of fluency and almost a shortcut to explaining the goal in real terms. Nobody is hunting and pecking at 80wpm.
      • bluefirebrand 1y ago
        Maybe nobody is hunting and pecking at 80wpm but I am not exaggerating when I say one of the best devs I've worked with was a hunt+peck typist The fact is that programming is not about typing lines of code into an editor
        • Xss3 1y ago
          I often out think my typing pace and have to cache ideas. The faster you can offload cache the less you end up having to manage. It's an effective way to rapidly reduce cognitive load and if it isn't in your toolbox then you're missing out on a valuable bit of kit.
    • 1y ago
• smoothdev-bp 1y ago
  I dont think the authors comments are without merit. My experience has shown me issues are usually more upfront and after the fact. Either the bottleneck between product organizations and engineering on getting decent requirements to know what to build and engineering teams being unwilling to start until they have every I dotted and T crossed. The backend of the problem is that already most of the code e see written is poorly documented across the spectrum. How many commit messages have we seen of "wip" for instance? Or you go to a repository and the Readme is empty? So the real danger is the stack overflow effect on steroids. It's not just a block of code that was put in that wasn't understood, its now entire projects, and there's little to no documentation to explain what was done or why decisions were made.
  • mgaunard 1y ago
    In my experience the difficulty in building good software is having a good vision of what the end result should look like and how to get there. If the developer is not savvy about the business case, he cannot have that vision, and all he can do is implement requirements as described by the business, which itself doesn't sufficiently understand technology to build the right path.
    • nkjoep 1y ago
      I tend to agree. Ideas are cheap and can be easily steered around. The tricky part is always the action plan: how do we achieve X in steps without blowing budget/time/people/other resources?
• gabrielso 1y ago
  The article misses the point that LLMs are not removing the bottleneck of writing code for people who know how to write code. It's removing this bottleneck for everyone else.
  • CerebralCerb 1y ago
    I have yet to see anyone who previously could not write code be able to do so, beyond simple scripts, with LLM's.
    • gabrielso 1y ago
      In my experience, non-coders with LLMs can go beyond simple scripts and build non-trivial small applications nowadays, but the difference of outcomes between them and a competent coder with LLMs is still staggering.
    • oc1 1y ago
      At least they will be more confident than ever that they can when all the LLM ever says is "You are absolutely right!" ;)
    • bubblyworld 1y ago
      I have - somebody in my mushroom foraging group wrote an app that predicts what kinds of mushrooms you are likely to find in different spots in our area, based on weather forecasts and data he's been collecting for years. It's a dead simple frontend/backend, but it works, he built and deployed it himself and he had zero coding experience before this. Pretty impressive, from my perspective. As a programmer I can see all the rough edges but that doesn't seem to bother the other 99% of people on the group who use it.
  • dankobgd 1y ago
    Then human resource woman should be the only programmer
• afiodorov 1y ago
  Even without LLMs, we were approaching a point of saturation where software development was bottlenecked by market demand and funding, not by a shortage of code. Our tooling has become so powerful that the pure act of programming is secondary. It's a world away from when the industry began. There's a great story from Bill Gates about a time when his ability to simply write code was an incredibly scarce resource. A company was so desperate for programmers that they hired him and Paul Allen as teenagers: "So, they were paying penalties... they said, 'We don’t care [that they are kids].' You know, so I go down there. You know, I’m like 16, but I look about 13. They hire us. They pay us. It’s a really amazing project... they got a kick out of how quickly I could write code." That story is a powerful reminder of how much has changed. Writing code was the bottleneck years ago. However the core problem has shifted from "How do we build it?" to "What should we build and is there a business for it?" Source: https://youtu.be/H1PgccykclM?si=YuIFsUcWc6sHRkAg https://youtu.be/H1PgccykclM?si=YuIFsUcWc6sHRkAg
  • OtherShrezzing 1y ago
    >Even without LLMs, we were approaching a point of saturation where software development was bottlenecked by market demand and funding, not by a shortage of code I think it's credible to say that it was just market demand. Marc Andreessen's main complaint before the AI boom was that "there is more capital available than there are good ideas to fund". Personally, I think that's out of touch with reality, but he's the guy with all the money and none of the ideas, so he's a credible fist-hand source.
    • afiodorov 1y ago
      I think the "more capital than ideas" problem is highly contextual and largely a Silicon Valley-centric view. There is immense, unmet demand for good software in developing countries—for example, robust applications that work well on underpowered phones and low-bandwidth networks across Africa or Southeast Asia. These are real problems waiting for well-executed ideas. The issue isn't a lack of good ideas, but a VC ecosystem that throws capital at ideas of dubious utility for saturated markets, while overlooking tangible, global needs because they don't fit a specific hyper-growth model.
• mgaunard 1y ago
  Right, we all know this. LLMs write a lot of bad code that cannot be realistically reviewed. I've even had code submitted to me by juniors which didn't make any sense. When I ask them why they did that, they say they don't know, the LLM did it. What this new trend is doing is generating a lot of noise and overhead on maintenance. The only way forward, if embracing LLMs, is to use LLMs also for the reviewing and maintenance, which obviously will lead to messy spaghetti, but you now have the tools to manage that. But the important realization is that for most businesses, quality doesn't really matter. Throwaway LLM code is good enough, and when it isn't you can just add more LLM on top until it does what you think you need.
  • djeastm 1y ago
    >When I ask them why they did that, they say they don't know, the LLM did it. I can't imagine a professional software developer in a position of authority leaving that statement unchallenged and uncorrected. If a person doesn't stand behind the code they write, they shouldn't be employed. Full stop.
    • mgaunard 1y ago
      The person in question was a junior. Of course I didn't approve the PR.
  • JonChesterfield 1y ago
    > When I ask them why they did that, they say they don't know, the LLM did it. This should resolve itself via rounds of redundancies, probably targetting the senior engineers that are complaining about the juniors, then by insolvency.
  • emporas 1y ago
    >LLMs write a lot of bad code that cannot be realistically reviewed. It can be reviewed. The job descriptions I have encountered so far, (thousands of them), not one of them mentions reading fast as a skill even more important that writing/typing. Put it another way, I have yet to go to an interview with the sole purpose of reading code, and writing code as an insignificant detail. For example: 5 years of reading Python/Django code as experience. Anyway that's gonna change, reading code/documentation fast, not even reviewing just reading, is the skill of utmost importance to hire for! Donald Knuth: “Programs are meant to be read by humans and only incidentally for computers to execute.” [1] [1] https://www.goodreads.com/quotes/6086714-programs-are-meant-to-be-read-by-humans-and-only https://www.goodreads.com/quotes/6086714-programs-are-meant-...
• revskill 1y ago
  Nan, it depends on quality of data you trained the bot.
• gdiamos 1y ago
  I used to think I needed to type faster. As I get older I spend more of my coding time on walks, at the whiteboard, reading research, and running experiments
  • Cthulhu_ 1y ago
    Exactly; it's not about the volume of code, it's about the value of it. The best code is the code never written. Reminds me of a former colleague of mine, I'd sit next to him and get frustrated because he was a two-finger typer. But, none of his code was wasted. I frequently write code, then cmd+z back to ten minutes ago or just `git checkout .` because I lost track.
    • rightbyte 1y ago
      Ye. The occassions were typing speed is even remotely important are so rare. Like, when you make a totally new file or class and need to churn out the skeleton.
  • marcosdumay 1y ago
    Programmers don't have to type fast, but we have to type unconsciously. Training for one of those usually also trains for the other.
• aitchnyu 1y ago
  Has anybody previously had Gantt chart paths "non-code-1 -> code-1 -> non-code-2 =-> code-2" and transformed them into coding tasks, and taking advantage of the newfound coding speed? What did you do? I would need buy-in from people.
• andrelaszlo 1y ago
  My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "good catch, I'll fix that" (also reminiscent of an LLM). - The time spent on trivial issues went down a lot, almost zero, the remaining issues were much more subtle and time-consuming to find and describe. - Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This breakdown of pattern-matching compared to "organic" code made the overhead much higher. Spending decades reviewing code and answering Stack Overflow questions often makes it possible to pinpoint not just a bug but how the author got there in the first place and how to help them avoid similar things in the future. - A simple, but bad (inefficient, wrong, illegal, ugly, ...) solution is a nice thing to discuss, but the LLM-assisted junior dev often cooks up something much more complex, which can be bad in many ways at once. The culture of slowly growing a PR from a little bit broken, thinking about design and other considerations, until its high quality and ready for a final review doesn't work the same way. - Instead of fixing the things in the original PR, I'd often get a completely different approach as the response to my first review. Again, often broken in new and subtle ways. This lead to a kind of effort inversion, where senior devs spent much more time on these PRs than the junior authors themselves. The junior dev would feel (I assume) much more productive and competent, but the response to their work would eventually lack most of the usual enthusiasm or encouragement from senior devs. How do people work with these issues? One thing that worked well for me initially was to always require a lot of (passing) tests but eventually these tests would suffer from many of the same problems
  • agumonkey 1y ago
    Somehow interesting how this is similar to other uses of ML driven tools, like electronics engineering where solutions would be near impossible to understand for experienced engineers.
  • epolanski 1y ago
• oc1 1y ago
  Yep, code won't matter in the future. Code isn't the bottleneck anymore and it's a good liberation for us professional developers. Now we can move on.
  • bluefirebrand 1y ago
    Code never was the bottleneck though
• kulahan 1y ago
  This shouldn't be surprising to anyone in software development. Regardless of how essential your software is, you can just shit out any stupid-ass thing that vaguely works and you've finished your ticket. Who thought lazy devs were the bottleneck? The industry needs 8x as much regulation as it has now; they can do whatever they want at the moment lol.
• am17an 1y ago
  One thing I despise about LLMs is transferring the cognitive load to a machine. It’s just another form of tech debt. And you have repay it pretty fast as the project grows.
• kabdib 1y ago
  my LLM win this year was to give the corporate AI my last year's worth of notes, emails and documents and ask it to write my self review. it did a great job. i'm never writing another one of those stupid bits of psychological torture again otherwise i'm writing embedded systems. fine, LLM, you hold the scope probe and figure out why that PWM is glitching
  • williamdclt 1y ago
    That's a really good idea, and would have the double-benefit that it would incentivise me to keep better track of information and communication, as well as take more notes, all of which certainly has various other benefits.
  • ysofunny 1y ago
    but as soon as you are doing that, the people who have to read your self-review will simply throw what you gave them into their own instance of the same corporate AI at which point why not simply let the corporate AI tell you what to do as your complete job description; the AI will tell you to "please hold the scope probe as chatbotAI branding-opportunity fixes the glitches in the PWM" I guess we pass the butter now...
• 2d8a875f-39a2-4 1y ago
  The author puts the BLUF: "The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication." They're not wrong, but they're missing the point. These bottlenecks can be reduced when there are fewer humans involved. Somewhat cynically: code reviews: now sometimes there's just one person involved (reviewing LLM code) instead of two (code author + reviewer) knowledge transfer: fewer people involved means this is less of an overhead debugging: no change, yet coordination and communication: fewer people means less overhead LLMs shift the workload — they don’t remove it: sure, but shifting workload onto automation reduces the people involved Understanding code is still the hard part: not much change, yet Teams still rely on trust and shared context: much easier when there are fewer people involved ... and so on. "Fewer humans involved" remains a high priority goal for a lot of employers. You can never forget that.
• noelwelsh 1y ago
  > The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals. Most of these only exist because one person cannot code fast enough to produce all the code. If one programmer was fast enough, you would not need a team and then you wouldn't have coordination and communication overhead and so on.
  • brazzy 1y ago
    That hypothetical one person would not just need to produce the code, but also understand how it fulfills the requirements. Otherwise they are unable to fix problems or make changes. If the amount of code grows without bounds and is an incoherent mess, team sizes may not, in fact, actually get smaller.
    • noelwelsh 1y ago
      Agreed. I don't think anyone can produce useful code without understanding what it should do. One useful dimension to consider team organization is the "lone genius" to "infinite monkeys on typewriters" axis. Agile as usually practised, microservices, and other recent techniques seem to me to be addressing the "monkey on typewriters" end of the spectrum. Smalltalk and Common Lisp were built around the idea of putting amazing tools in the hands of a single or small group of devs. There are still things that address this group (e.g. it's part of Rails philosophy) but it is less prominent.
• austin-cheney 1y ago
  Writing software is like a combination of writing a short story, cleaning your room, and planning a vacation. The bottleneck is always low confidence, much like work anywhere else. I have watched for almost 20 years employers try to solve and cheat their way around this low confidence. The result is always the same: some shitty form of pattern copy/paste, missing originality, and delivery timelines for really basic features. The reasons for this is that nobody wants to invest in training/baselines and great fear that if they do have something perceived as talent that its irreplaceable and can leave. My current job in enterprise API management is the first time where the bottleneck is different. Clearly the bottleneck is the customer’s low confidence, as opposed to the developers, and manifests as a very slow requirements gathering process.
• Schnitz 1y ago
  I think a lot of teams will wrestle with the existing code review process being abused for quite a while. A lot of people are lazy or get into tech because it’s easy money. The combination of LLMs and a solid code review process means you can submit slop and not even be blamed for the results easier than ever.
• threemux 1y ago
  In a professional setting, I agree 100%, no notes. Where LLMs have helped me the most are actually side projects. There, writing the code is absolutely the bottleneck - I literally can't (or perhaps won't is more truthful) allocate enough time to write code for the little apps I've thought of to solve some small problem.
  • dgellow 1y ago
    Agreed fully, if I have 1-2 hours a day with Claude code I end up the week with a personal project I can actually use. Or spend like half a weekend day to see if an idea makes sense. But I think that makes them invaluable in professional contexts. There is so much tooling we never have the time to write to improve stuff. Spend 1-2h with Claude code and you can have an admin dashboard, or some automation for something that was done manually before. A coworker comes to me with a question about our DB content, Claude gives me a SQL query for what they need, review, copy paste to Metabase or Retool, they now don’t have to be blocked by engineering anymore. That type of things has been my motivation for mcp-front[0], I wanted my non-engs coworkers to be able to do that whole loop by themselves. [0] https://github.com/dgellow/mcp-front https://github.com/dgellow/mcp-front
    • mritchie712 1y ago
      we specialize in "don't ask engineering for SQL" at https://www.definite.app/ https://www.definite.app/. we spin up a data lake, load all your data and educate an agent on your data.
    • wombatpm 1y ago
      Obligatory xkcd https://xkcd.com/1205 https://xkcd.com/1205
  • Cthulhu_ 1y ago
    A fair point; at this point in my career, I can't just spend weeks on something, plus I know all of the non-functionals and longer-term things I should keep in mind. Even when skipping things like tests, things just cost more work.
  • 1y ago
• albertojacini 1y ago
  The title says it all
• khazhoux 1y ago
  Yet another article trying to take away from the impact of LLMs. This one is more subtle than most, but still the message is "this problem that was solved, was never actually the problem." Except... writing code is often a bottleneck. Yeah, code reviews, understanding the domain, etc, is also a bottleneck. But Cursor lets me write apps and tools in 1/20th the time it would take me in an area where I am an expert. It very much has removed my biggest bottleneck.
  • Aeglaecia 1y ago
    I feel like the author gave a pretty balanced take by recognising multiple ends of the equation ... do you yourself recognise that such the speedup described in your perspective is contingent on the environment that you have applied llms to? regarding frontend , wysiwyg , this is an environment where edge cases are deprioritized and llms thus excel. on the other hand working in an environment reliant on non publicly available technical documentation , llms are borderline useless. and in an environment where edge cases are paramount , llms actively cause harm , as described elsewhere in the thread. these three environments are concurrently true , they do not detract from each other ..
• alkonaut 1y ago
  I agree with most of this. Writing code is one of the easy bits of Software Development. Writing the specifications about what to write is hard. Once you can specify what to create, and do it well, then actually creating it is quite cheap. However, as a software developer that often feel I'm pulled into 10 hours of meetings to argue the benefits of one 2-hour thing over the other 2-hour thing, my view is often "Lets do both and see which one comes out best". The view of less technical participants in meetings is always that development is expensive, so we must at all cost avoid developing the wrong thing. AI can really take hat equation to the extreme. You can make ten different crappy and non-working proof-of-concept things very cheaply. Then throw them out and manually write (or adapt) the final solution just like you always did. But the hard part wasn't writing the code, it was that meeting where it was decided how it should work. But just like discussing a visual design is helped by having sketches, I think "more code" isn't necessarily bad. AI's produce sub par code very quickly. And there are good uses for that: it's a sketch tool for code.
  • bluefirebrand 1y ago
    > AI's produce sub par code very quickly. And there are good uses for that: it's a sketch tool for code The problem is that the business bleepheads see the thing work (badly) and just say "looks great as is, let's ship it" and now you're saddled with that crap code forever
• padjo 1y ago
  I saw one tech company say they’re going to measure the impact of AI tools by counting merged pull requests per engineer. Seems like I great recipe for AI bullshit churn counting as positive impact.
• AbstractH24 1y ago
  The difference between a hobbyist who codes and a professional is all of the things listed in this article. As someone who shamefully falls more in the hobbyist camp, even when they code in the workplace, and has always wanted to cross what I perceived as a chasm, I’m curious, where did most people who code for a living learn these skills?
  • tigroferoce 1y ago
    years of experience and iterations
  • dgellow 1y ago
    To answer the “where”, the response is in a workplace environment. Some people seem to be able to develop that set of skills by joining serious open source projects. But really, you have to learn that on the spot. Great teams do take that in account and will train newcomers in what it means to be a “professional” developer. But then the question becomes, how do you find such a team? And I don’t think there is a trick here. You have to look around, follow people who seem great, try to join teams and see how it goes
  • mreid 1y ago
    A lot of those skills come from thinking about development in a team as a system and ask where do things frequently go wrong or take too long? Practice clearly and concisely expressing what you understand the problem to be. This could be a problem with some code, some missing knowledge, or a bad process. Check to see whether everyone understands and agrees. If not, try to target the root of the misunderstanding and try again. Sometimes you’ll need to write a short document to make things clear. Once there is a shared understanding then people can start taking about solutions. Once everyone agrees on a solution, someone can go implement it. Like any skill, if you practice this loop often enough and take time to reflect on what worked and what didn’t, you slowly find that you develop a facility for it.
• throwaw12 1y ago
  I will disagree with the author. If you look from the lenses of BigTech and corporations, yes code was not a bottleneck. But, if you look from the perspective of startups, rigorous planning was because resources to produce features were limited, which means producing a working code was a bottleneck, because in small teams you don't have coordination overhead, idea and vision is clear for them -> to produce something they have discussed and agreed on already. My takeaway is, when discussing broad topics like usefulness of AI/LLM, don't generalize your assumptions. Code was bottleneck for some, not for others
  • Sammi 1y ago
    What I've seen is exactly this, that LLMs give the most leverage to small and highly capable teams of devs. You need to be highly capable in order to get good output from LLMs, and large teams still have the coordination overhead that slows them down. LLMs supercharge the small teams that were already good.
  • zhobbs 1y ago
    I think another generalization people make here is around complexity. Many developers work on apps that just aren't that complex. Glorified CMS's mostly doing CRUD with well established code patterns. Sure, LLMs might create slop on novel problems, but a non-tech company that needs to "create a new CRUD route" and an accompanying form, LLMs are smart enough.
    • lokar 1y ago
      I agree. I spent most of my career on complex distributed infrastructure. I spent most of my time reading and thinking, not coding.
• aosmith 1y ago
  This resonates a little, it's problems that you need to consider... When I quit smoking I noticed my code quality dropped. It wasn't because I missed the cigarettes, it was the mental break with a solid social excuse I was missing. I started taking smoke breaks, without the smoke and things returned to normal.
• worldsayshi 1y ago
  I think the bottleneck can be summarized as verification and understanding. While that was the bottleneck before as well now it makes even more sense to find comprehensive ways to work with that. If you can quickly verify that the code is doing the right thing and that it is understandable, then you might achieve productivity increase. And there's no good reason why LLM's can't at least partially help with that.
• lionkor 1y ago
  The difference between AI as autocomplete and vibe coding couldn't be bigger. It's like the difference between having your phone with you on a trip somewhere to take pictures with, and just watching a video of the place on your phone at home. Autocomplete speeds up code generation by an order of magnitude, easily, with no real downside when used by experienced devs. Vibe coding on the other hand completely replaces the programmer and causes lots of new issues.
  • bluefirebrand 1y ago
    > Autocomplete speeds up code generation by an order of magnitude, easily, with no real downside when used by experienced devs Strongly disagree. Autocomplete thinks slower than I do, so if I want to try and take advantage of it I have to slow myself down a bunch Instead of just writing a function, I write a line or two, wait to see what the auto complete suggests, read it, understand it, often realize it is wrong and then keep typing. Then it suggests something else, rinse, repeat I get negative value from it and turned it off eventually. At least intellisense gives instant suggestions ...
  • RedNifre 1y ago
    Strongly disagree. The only instance where autocomplete helped me was a situation where I would have required macros, so I typed out the first 3 cases manually and had autocomplete generate the next 20. In all other cases, autocomplete was never faster than writing it myself. Full code generation, where you can step away from the computer for 20 minutes, does save me time.
• z3t4 1y ago
  When I learned coding it took a lot of effort just to get something to work at all, it took many years until I could take an idea and write code that works right away after the spelling errors have been fixed. Now I have colleges that have no idea what they're doing but AI gives them code that works... Meanwhile the coding standards, languages and frameworks changes faster then I have time to keep up. I always liked code that was simple, easy to understand, and easy to change, remove and rewrite. Writing and working with such code is very satisfying. But noone cares about code anyway. It's more of an brutalist abstract artform that very few people appreciate.
• brokegrammer 1y ago
  For me, writing CSS and coming up with professional looking designs were huge bottlenecks. Now I delegate those tasks to LLMs. I recently started working on a client's project where we were planning on hiring a designer to build the front-end UI. Turns out, Gemini can generate really good UIs. Now we're saving a lot of time because I don't have to wait on the designer to provide designs before I can start building. The cost savings are most welcome as well. Coding is definitely a bottleneck because my client still needs my help to write code. In the future, non-programmers should be able to build products on their own.
  • hn_throw2025 1y ago
    This is something that’s been in my mind too. I don’t think there’s enough distinction between using LLMs for frontend and backend in discussions similar to these. Using it for things like CSS/Tailwind/UI widget layout seems like a low risk timesaver.
• dmezzetti 1y ago
  There has long been ways to reduce writing boilerplate code with IDEs. AI code generation is just another tool and it will help enable competent people.
  • bluefirebrand 1y ago
    Not unless it is deterministic If I have to manually review the boilerplate after it generates then I may as well just write it myself. AI is not improving this unless you just blindly trust it without review, AND YOU SHOULDN'T
    • dmezzetti 1y ago
      I'm not sure many seasoned developers are really using AI that much in their workflows.
      • bluefirebrand 1y ago
        If they aren't I wish they would speak up more and push back against management more If there's a secret, silent majority of seasoned devs who are just quietly trying to weather this, I wish they would speak up But I guess just getting those paycheques is too comfy
        • dmezzetti 1y ago
          Software managers have long pushed "productivity" tools on developers. Most don't stick and this is likely similar. It's best to hire smart people and let them use whatever stack works best for them.
• sublimefire 1y ago
  A bit more interesting is slightly inverse to this. What will win in the next 10 years? IMO expectations are now so high from users that you need to create websites, apps, auth, payment integration, customer supoort forums and chats. And this is to break the ice and have a good footing for the business to move forward. You could see how this is a problem for a non technical person. Nobody will hire someone to do all that as it will be prohibitively expensive. AI is not for the engineers, it is a “good enough” for folks that do not understand the code. A lot depends on where the money will be invested, and what will consumers like as well. I bet the current wave of ai coding will morph into other spheres to try and improve efficiency.
  • bGl2YW5j 1y ago
    I can’t get over the idea that I won’t ever trust my data to a product made entirely by AI; one with no or limited human oversight.
• throwaway63783 1y ago
  I woke up saying “no” into my pillow over and over again this morning about this problem. There are two ways forward: - Those of us that have been vibing revert to having LLMs generate code in small bits that our brains are fast enough to analyze and process, but LLMs are increasingly optimized to create code that is better and better, making it seem like this is a poor use of time, since “LLMs will just rewrite it in a few months.” - We just have a hell of a time, in a bad way, some of us losing our jobs, because the code looks well-thought out but wasn’t, at ever increasing scale. I have wavered over the past months in my attitude after having used it to much success in some cases and having gotten in over my head in beautiful crap in the more important ones. I have (too) many years of experience, and have existed on a combination of good enough, clear enough code with consideration for the future along with a decent level of understanding, trust in people, and distrust in scenarios. But this situation is flogging what remains of me. Developers are being mentored by something that cannot mentor and yet it does, and there is no need for me, not in a way that matters to them. I believe that I’ll be fired, and when I am, I may take one or both of two roads: 1. I’ll continue to use LLMs on my own hoping that something will be created that feeds my family and pays the bills, eventually taking another job where I get fired again, because my mind isn’t what it was. 2. I do one of the few manual labor jobs that require no reasoning and are accepting of a slow and unreliable neurodivergent, if there are any; I don’t think there truly are. I’ve been close to #2 before. I learned that almost everything that is dear to you relies on your functioning a certain way. I believe that I can depend on God to be there for me, but beyond that, I know that it’s on me. I’m responsible for what I can do. LLMs and those AIs that come after them to do the same- they can’t fill the hole in others’ lives the way that you can, even if you’re a piece of shit like I am. So, maybe LLMs write puzzling code as they puzzle out our inane desires and needs. Maybe we lose our jobs. Maybe we hobble along slowly creating decent code. It doesn’t matter. What matters is that you be you and be your best, and support others.
• richx 1y ago
  I work on business software. I think one very important aspect is requirements collection and definition. This includes communicating with the business users, trying to understand their issues and needs that the software is supposed to address. And validating if the actual software is actually solving it or not (sufficiently). All of this requires human domain knowledge, communication and coordination skills.
• neoden 1y ago
  > Now, with LLMs making it easy to generate working code faster than ever, a new narrative has emerged: that writing code was the bottleneck, and we’ve finally cracked it. This narrative is not new. Many times I've seen decisions were made on the basis "does it require writing any code or not". But I agree with the sentiment, the problem is not the code itself but the cost of ownership of this code: how it is tested, where it is deployed, how it is monitored, by whom it's maintained etc.
• marginalia_nu 1y ago
  I think most of the supposed bottlenecks are mostly a consequence of attempting to increase development speed by throwing additional developers at the problem. They're trivially problems that don't exist for a solo dev, and there's a strong argument that a small team won't suffer much from them either. If you can use tools to increase individual developer productivity (let's say all else being equal, code outputs 2x as fast) in a way where you can cut the team size in half, you'll likely a significant productivity benefit since your communication overhead has gone down in the process. This is of course assuming a frictionless ideal gas at STP where the tool you're looking at is a straight force multiplier.
• ogou 1y ago
  My last job had a team with about 50% temp and contract. When the LLMs got popular, I could tell right away. When I reviewed their code, it was completely different than their actual style. The seniors pushed back because it was costing us more time to review and we knew it was generated. Also, they couldn't talk about about what they did in meetings. They didn't know what it was really doing. Eventually the department manager got tired of our complaining and said "it's all inevitable." Then those mercenaries started to just rubber stamp each other's PRs. The led to some colossal fuckups in production. Some of them were fired quietly, and the new people promptly started doing the same thing. Why should they care, it's just a short term contract on the way to the big payday, right?
• gexla 1y ago
  In addition to the poor code we spend time on, we get to lose even more time endlessly talking about it and working on ways around the issues. I swear I have spent as much time tinkering with these models and the tooling as it took for me to bring my first skills up to a level to get hired. For people who are asking me if "ChatGPT can build a web app," they're really asking if they can build this thing without learning anything. I have bad news for them...
• dxroshan 1y ago
  The author doesn't give any arguments to support his claim.
• al_borland 1y ago
  The most outspoken person against LLMs on my team would bring this up a lot. Though the biggest bottleneck he identified was the politics and actually coming to agreements on spec of what to write. Even with perfect AI software engineers, this is still the issue, as someone still needs to tell the AI what to do. If no one is willing to do that, what’s the point of any of this?
• whatevsmate 1y ago
  Wow a lot of the stories people are writing here are super depressing. If a junior developer is delivering you a pile of code that doesn’t work, hasn’t been manually tested and verified by them, hasn’t been carefully pared down to its essential parts, and doesn’t communicate anything about itself either through code style, comments or docs … then you are already working with an LLM ; it just so happens to be hosted in - or parsed thru - a wetware interface. Critical thinking and taking responsibility for the outcome is the real job and always has been. And, cynically, I bet a software LLM will be more responsive to your feedback than the over-educated and overpaid junior “engineer” will be. Actually I take it back, I don’t think this take is cynical at all.
  • raincole 1y ago
    People think juniors submitting LLM-generated code to seniors to review is a sign of how bad LLM is. I see it as a sign of how bad juniors are, and the need of seniors interacting with LLM directly without the middlemen.
    • m_mueller 1y ago
      The main problem in this environment is IMO: how does a junior become a senior, or even a bad junior become a good junior. People aren't learning fundamentals anymore beyond what's taught, and all the rest of 'trade knowledge' is now never experienced, people just trust that the LLM has absorbed it sufficiently. Engineering is all about trade-offs. Failing to understand why from 10 possible ways of achieving something, 4 are valid contenders and possible 1-2 are best in the current scenario, and even the questions to ask to get to that answer, is what makes a senior.
      • whatevsmate 1y ago
        The LLM is the coding tool, not the arbiter of outcome. A human’s ability to assess, interrogate, compare, research, and develop intuition are all skills that are entirely independent of the coding tool. Those skills are developed through project work, delivering meaningful stuff to someone who cares enough to use it and give feedback (eg customers), making things go whoosh in production, etc etc. This is a XY problem and the real Y are galaxy brains submitting unvalidated and shoddy work that make good outcomes harder rather than easier to reach.
• AshleysBrain 1y ago
  This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1". If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making. [1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-time-spent-reading-versus-writing-is https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...
  • kgwgk 1y ago
    Even worse, in some cases it may be decreasing the writing time and increasing the reading time without reducing the total work.
  • pragmatic 1y ago
    Unfortunately, the micro-methods his clean coding style oroduce ends up doing the exact opposite. Context is never close at hand, it is scattered all over the place defeating the purpose.
  • JonChesterfield 1y ago
    That ratio no longer holds if people don't look at the code, they just feed it back into a new llm. People used to resist reading machine generated output. Look at the code generator / source code / compiler, not at the machine code / tables / xml it produces. That resistance hasn't gone anywhere. Noone wants to read 20k lines of generated C++ nonsense that gcc begrudgingly accepted, so they won't read it. Excitingly the code generator is no longer deterministic, and the 'source code prompt' isn't written down, so really what we've got is rapidly increasing piles of ascii-encoded-binaries accumulating in source control. Until we give up on git anyway. It's a decently exciting time to be in software.
  • draw_down 1y ago
    [dead]
  • emporas 1y ago
    No one is hiring though for reading code. I have read 10 million lines of code, roughly, I have written not one line. Now I have produced a lot of programs, just by reading them. People should also learn how to read programs. Most open source code is atrocious, corporate code is usually even worse, but not always. As Donald Knuth once said, code is meant to be read. The time of literate programming is gonna come at some point, either in 100 years or in 3 years.
• pjmlp 1y ago
  That is why there is a being difference between being a sofware engineer, or software developer roles, and a plain coder, and titles carry more than words.
• bobsmooth 1y ago
  I'm less concerned with professionals using LLMs to code and more excited by the idea of regular people using LLMs to create programs that solve their problems.
• desio 1y ago
  Maybe true, but not true enough.
• calrain 1y ago
  I've always enjoyed software design, for me the coding was the bottleneck and it was frustrating as I had to roll through different approaches when I so clearly knew the outcome that I wanted. Using Claude Code to first write specs, then break it down into cards, build glossaries, design blueprints, and finally write code, is just a perfect fit for someone like me. I know the fundamentals of programming, but since 1978 I've written in so many languages that the syntax now gets in the way, I just want to write code that does what I want, and LLM's are beyond amazing at that. I'm building API's and implementing things I'd never dreamed of spending time on learning, and I can focus on what I really want, design, optimisation, simplification, and outcomes. LLM's are amazing for me.
  • pragmatic 1y ago
    Agreed LLMs are fantastic autocomplete for experts. Often giving 90% of what you need. But those junior devs…
• conartist6 1y ago
  My philosophy is dirt simple: I am the pointy end of the spear.
• orwin 1y ago
  I used Sonnet4 to write my last frontend task, fully, with minimal input. It is so much better than ChatGPT it's unbelievable, but while a 6hour coding task was transformed into a 30 minutes supervision task that generated good, but also correct code, I was a bit afraid for new engineers coming into an old project. How are you supposed to understand code if you don't at least read it and fail a bit? I'll continue using Sonnet4 for frontend personally, it always had been a pain point in the team and I ended up being the most knowledgeable on it. Unless it's a new code architecture, I will understand what was changed and why, so I have confidence I can handle rapid iteration of code on it, but my coworkers who already struggled with our design will probably have even more struggles. Sadly I think in the end our code will be worse, but we are a team of 5 doing the work of a team of 8, so any help is welcome (we used to do the work of 15 but our 10x developper sadly (for us) got caught being his excellent self by the CTO and now handle a new project. Hopefully with executive-level pay)
  • pragmatic 1y ago
    LLMs are fantastic at summaries and finding where XYZ happens. “Where is the customer entity saved to the database?”
    • deleted 1y ago
      [deleted]
• data_yum_yum 1y ago
  Code is always the bottleneck because people aren’t always thoughtful about how they design it. Coordination, communication, etc… honestly not that big of a deal if you have the right people. If you are working with the wrong people coordination and communication will never be great no matter what “coordination tools you bring in”. If you have a good team, we can be sending messenger pigeons for all o care and things will still work out. Just my opinions.
• ivolimmen 1y ago
  Thank you; this is exactly what was bothering me. This is my opinion as well you just found the words I could not find!
• afro88 1y ago
  This is a strawman isn't it? I haven't read one post or comment saying that writing code is "the bottleneck". It's something that takes time. That time is now greatly reduced. So you can try more ideas and explore problems by trying solutions quickly instead of just talking about them. Let's also not ignore the other side of this. The need for shared understanding, knowledge transfer etc is close to zero if your team is agents and your code is the input context (where the actual code is now at the level that machine code is now: very rarely if ever looked at). That's kinda where we're heading. Software is about to get much grander, and your team is individuals working on loosely connected parts of the product. Potentially hundreds of them.
• bob1029 1y ago
  I used to think authoring code was the bottleneck. It took a solid decade to learn that alignment of the technology to the business is the actual hard part. Even in the extreme case like a B2B/SaaS product wherein every customer has a big custom code pile. If you have the technology well aligned with the business needs, things can go very well. We have the technology to make the technology not suck. The real challenge is putting that developer ego into a box and digging into what drives the product's value from the customer's perspective. Yes - we know you can make the fancy javascript interaction work. But, does the customer give a single shit? Will they pay more money for this? Do we even need a web interface? Allowing developers to create cat toys to entertain themselves with is one realistic way to approach the daily cloud spend figures of Figma. The biggest tragedy to me was learning that even an aggressive incentive model does not solve this problem. Throwing equity and gigantic salaries into the mix only seems to further complicate things. Doing software well requires at least one person who just wants to do it right regardless of specific compensation. Someone who is willing to be on all of the sales & support calls and otherwise make themselves a servant to the customer base.
  • hbn 1y ago
    > alignment of the technology to the business is the actual hard part Yup. The tough part of my job has always been taking the business requirements and then figuring out what the business ACTUALLY wants. Users will tell you what they want, but users are not designers and usually don't think past what they currently want right now. Give them exactly what they say they want and it will almost never give a good result. You have to navigate consequences of decisions and level-set to find the solution. LLMs are not good at this and only seem to get worse as "improved" models find users prefer constant yes-manning. I've never had an LLM tell me my idea was flawed and that's a huge issue when writing software.
    • wombatpm 1y ago
      Should BOFH be a required source when training agents for interactions?
• konovalov-nk 1y ago
  Nobody mentioned Joel Spolsky's October 2nd, 2000 article, so I'll start: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/ https://www.joelonsoftware.com/2000/10/02/painless-functiona... Code is not a bottleneck. Specs are. How the software is supposed to work, down to minuscule detail. Not code, not unit tests, not integration tests. Just plain English, diagrams, user stories. Bottleneck is designing those specs and then iterating them with end users, listening to feedback, then going back and figuring out if spec could be improved (or even should). Implementing actual improvements isn't hard once you have specs. If specs are really good -- then any sufficiently good LLM/agent should be able to one-shot the solution, all the unit tests, and all the integration tests. If it's too large to one-shot -- product specs should never be a single markdown file. Think of it more like a wiki -- with links and references. And all you have to do is implement it feature by feature.
  • intelVISA 1y ago
    > How the software is supposed to work, down to minuscule detail. So... coding. :P
    • konovalov-nk 1y ago
      Code is a technical specification and could be any programming language, markup, terraform files, configuration, whatever. Product Spec is written in English and in a such way that everybody can understand it without technical knowledge. Because it doesn't operate in C arrays and nuances of how queues work -- just common sense and real-life objects/entities! Then the actual code is an abstraction that takes the spec and implements it for certain architecture / scalability requirements and so on. For example you can ask to make to-do list app. You can build it on: - As a CLI tool - As a UI web interface - As an AI agent that operates entirely on voice recognition and text-to-speech as interface A product spec can omit this "tiny" detail, code -- cannot. Even if you specify this is Web UI to-do app in product spec, there are still tons of things to choose for developer: - Programming language - Cloud/Self-hosted - Architecture (monolith/microservices/modular monolith/SOA/event-driven) You wouldn't specify in a Product spec that to-do items has to go to an SQS queue that lambda picks up and adds them to a DB, would you? That has to be a separate technical spec document, which is simply called documentation (+actual code in the repositories).
• alex_hirner 1y ago
  True. Therefore I'm eagerly awaiting an artificially intelligent product manager. Or I might build that myself.
• KronisLV 1y ago
  > The marginal cost of adding new software is approaching zero, especially with LLMs. But what is the price of understanding, testing, and trusting that code? Higher than ever. I’m not sure about that: the code LLMs generate isn’t categorically worse than that written by people who no longer work here and that I can’t ask anything to either. It’s also not much better or worse than what you’d find online but has a more broad reach than my Google-fu, alongside some hallucinations. At the same time, AI doesn’t hate writing tests because it doesn’t get a choice. It doesn’t get breaks and doesn’t half ass things any more or less depending on how close to 5 PM it is. Maybe my starting point is viewing all code as a liability and not trusting anything anyone (myself included) has written all that much, so the point doesn’t resonate with me that much. That said I have used AI to push out codebases that work, albeit that did take a testable domain and a lot of iteration. It produces results but also rots my brain somewhat because the actual part of writing code becomes less of a mentally stimulating activity compared to requirements engineering.
• pragmatic 1y ago
  Yes but no. It’s decisions. Ninety five percent is all the decisions made from every person involved. The fastest delivery I ever encountered were situations where the stakeholders were intimately familiar with the problem and made quick decisions. Only then did speed of coding affect delivery. In large organizations, PMs are rarely POs. Every decision needs to be run up the flagpole and through committee with CYAs and delays at every step. Decision makers are outsourcing this to LLMs now which is scary as they are supposed to be the SME. It’s the same old same old where the generals make decisions but the sergeants (NCOs) really run the army. That’s where I feel leads/principles/staff really make out break the product. They are the fulcrum dealing with LLM from above and below.
• injidup 1y ago
  LLMs are surprisingly good at writing test cases—something many developers either skip or struggle with. If you structure your workflow around TDD (Test-Driven Development), the LLM can generate and continuously rerun those tests as it iterates on the code. This creates a powerful closed-loop system where the spec (your unit tests) and the implementation evolve together. Multimodal LLMs take it even further. I've given Claude 4 a screenshot and simply said, “There’s too much white space.” It correctly identified the issue and generated CSS fixes. That kind of feedback loop could easily become a regression test for visual/UI consistency. This isn’t just about automating code generation—it’s about augmenting the entire development cycle, from specs to testing to visual QA.
• superkuh 1y ago
  Maybe it was never the bottleneck for paid software engineering at incorporated entities but it was definitely, 100%, the bottleneck for most human people. And now instead of having to get the help or code from an actual programmer, as a non-programmer but technical person, I can generate or alter any small trivial applications I want. I'm not going to be writing an OS or doing "engineering" but if I want to write a GUI widget to display my PCs temps/etc, or alter a massive complex C++ program to have some feature I want (like adding checkpointing to llama.cpp's fine-tune training), suddenly it's trivial and takes 15 minutes. Before it'd take days if it were feasible without help at all.
• perlgeek 1y ago
  > The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. I can relate :-) Our team maintains a configuration management database for a company that has grown mostly organically from 3 to 500+ employees in ~30 years. We don't have documented processes that would account for most of the write operations, so if we have a question, we cannot just talk to the process owner. The next option would be to talk to the data owner, but for many of our entities, we don't have a data owner. So we look into the audit logs to see which teams often touch the data, and then we do a meeting with some senior folks from each of these teams to discuss things. But of course, finding common meeting time slots with several senior people from several teams isn't easy, they're all busy. So that alone might delay something by a few weeks to months. For low-stakes decisions, we often try to not go through this effort, but instead do things that are easy to roll back if they go wrong. Once we have identified the stakeholders, have a common understanding among them, and a rough consensus on how to proceed, the actual code changes are often relatively simple in comparison. So, I guess this falls under "overhead of coordination and communication".
• netbioserror 1y ago
  All of these are the exact reasons I don't go overboard with a custom Vim or Helix setup with all sorts of bells and whistles, and just use stock Sublime. The real problem is never the speed at which I can write code. I need to model a complex problem domain. My choice of language and tools virtually eliminate all boilerplate and focus the effort on those modeling and software design problems. I've tried LLMs multiple times, and each time they've proven they cannot help me.
• NiloCK 1y ago
  Writing code was never the only bottleneck, and I'm sure there is personal variation, but for me personally it has always been the dominant bottleneck. My backspace and delete keys loom larger than the rest of my keyboard combined. Plodding through with meager fingers, I could always find fault faster than I could produce functionality. It was a constant, ego-depleting struggle to set aside encountered misgivings for the sake of maintaining forward progress on some feature or ticket. Now, given defined goals and architectural vision, which I've never been short of, the activation energy for producing large chunks of 'good enough' code to move projects forward is almost zero. Even my own oversized backspace is no match for the torrent. Again - personal variation - but I expect that I am easily 10x in both in ambition and in execution compared to a year ago.
  • cloverich 1y ago
    It's interesting to think about, but LLMs are perhaps not impacting everyone, even at the same level, the same ways. I'm similarly more productive, and for a different reason. I've always struggled with task persistence when the task is easy and monotonous.... or something. Easy jobs, books, code, that still took a while to do, always took the longest, focus was impossible. Hard tasks, books, classes, etc, i always did the best at. nearly failed school from the easiest course; highest marks in the hardest ones. I've never gotten over this. That's now melted away. For the first time my mind feels free to think. Everything is moving almost as fast as i am thinking, Im far less bogged down in the slow parts, which the llm can do. I spend so much more time thinking, designing, architecting, etc. Distracting thoughts now turn into completed quality of life features, done on the side. I guess it rewards add, the real kind, in a way that the regular world understandably punishes. And it must free up mental space for me because i find i can now review others prs more quickly as well. I don't use llm for this, and don't have a great explanation for what is happening here. Anyways im not sure this is the same issue as yours, and so its interesting to think about what kinds of minds it's freeing, and what kinds its of less use to.
• pclowes 1y ago
  I have not found LLMs to be most beneficial in straight writing code especially in complex large scale systems. However, I have found them extremely useful at the aspects the author claims they make more difficult: understanding, testing, and trusting that code. An LLM is an extremely useful search engine. Given access to plenty of CLI tools asking it questions about an unfamiliar code base is extremely helpful. It can read and summarize much faster than I can. I don't trust its exact understanding but I do trust it to give me a high level understanding of an architecture, call out dependencies, summarize APIs, and give me an idea of what parts of the code base are new/old etc. Additionally, having LLMs write tests after setting up the rough testing structure and giving it a few examples massively decreases the amount of time it takes to prove my understanding of the code through the tests thereby increasing my confidence/trust in it.
• tomasreimers 1y ago
  I've felt like a broken record the past few weeks, but this. Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck. The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there. For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or automate it (better, more intelligent CI), or--ideally---both. The tools we have are outdated, and if you're a team with more than 50 eng you've already spun up a sub team (devx, dev velocity, or dev productivity) whose job is to address this. Despite that, industry wide, we've still done very little because it's a philosophically poorly understood part of the process (why do we do code review? Like seriously, in three bullet points what's the purpose - most developers realize they haven't thought that deeply here). https://graphite.dev https://graphite.dev
  • Dumblydorr 1y ago
    What is the purpose of code review in three points? I’ll take a try, let me know other thoughts! -functionality, does it work? And is it meeting reqs? -bug prevention, reliability, not breaking things -matching of system architecture and best practices for the codebase Other ideas: -style and readability -learning for the junior and less so the senior probably -checking the “code review” box off your list
  • hakunin 1y ago
    I don't honestly know why most people do code reviews, because it's often presented as some kind of "quick sanity check" or "plz approve". Here's why we do code reviews where I get to lead the practice: 1. Collaborate asynchronously on architectural approach: (simplify, avoid wheel reinvention) 2. Ask "why" questions, document answers in commits and/or comments to increase understanding 3. Share knowledge 4. Bonus: find issues/errors There are other benefits, like building rapport, getting some recognition for especially great code. To me code reviews are supposed to be a calm process that takes time, not a hurdle to quickly kick out of the way. Many disagree with me however, but I'm not sure what the alternative is. Edit: people tend to say reviews are for "bug finding" and "verifying requirements". I think that's at best a bonus side effect, that's too much to ask a person merely reading the code. In my case, code reviews don't go beyond reading the code (albeit deeply, carefully). We do however have QA that is more suited for verifying overall functionality.
• TYPE_FASTER 1y ago
  1. Define the problem you are trying to solve. 2. Propose a solution to the problem and get feedback. 3. Design the data model(s) and get feedback. 4. Design the system architecture and get feedback. 5. Design the software architecture and get feedback. 6. Write some code and get feedback. 7. Test the code. 8. Let people use the code. Writing the code is only one step. In all honesty, I expect over time intelligent agents will be used for the other steps. But the code is based on the proposed solution, which is based on the problem statement/requirements. The usefulness of the code will only be as good as the solution, which will only be as good as the problem statement/requirements.
• kazinator 1y ago
  There are times when writing the code is a bottleneck. It's not everyday code. You don't quite know how to write the code. Whatever you try breaks somehow, and you don't readily understand how, even though it is deterministic and you have a 100% repro test case. An example of this is making changes to a self-hosting compiler. Due to something you don't understand, something is mistranslated. That mistranslation is silent though. It causes the compiler to mistranslate itself. That mistranslated compiler mistranslates something else in a different way, unrelated to the initial mistranslation. Not just any something else is mistranslated, but some rarely occurring something else. Your change is almost right: it does the right thing with numerous examples, some of them complicated. Making your change in the 100% correct way which doesn't cause this problem is like a puzzle to work out. LLM AI is absolutely worthless in this type of situation because it's not something you can wing from the training data. It's not a verbal problem of token manipulation. Sure, if you already know how to code this correctly, then you can talk the LLM through it, but it could well be less effort just to do the typing. However, writing everyday, straightforward code is in fact the bottleneck for every single one of the LLM cheerleaders you encounter on social networks.
• sorcercode 1y ago
  _about 2 years back. I pushed back hard with a similar argument but I have since come around._ I think the premise is true that writing code was never the "main" bottleneck but like any power tool, when wielded by the right person, it can blow past bottlenecks. many of these arguments,only assume the case of an inexperienced engineer blindly pumping out and merging code. I concede the problems in this case. but put this to test with more experienced engineers. how has/does it change their workflows? the results (I've personally observed) are exponentially different. --- > LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability. I have to strongly disagree here. this argument doesn't apply universally. I've actually found LLMs to make it easier to understand large swaths of code, faster. especially in larger codebases that have legacy code that no one has worked on or dared to touch. LLMs bring an element of fearlessness, which makes it easier to effect change.
  • chanux 1y ago
    > I've actually found LLMs to make it easier to understand large swaths of code, faster. If you have written about your workflow related to this outcome, appreciate if you share.
    • sorcercode 1y ago
      gladly. i haven't written about this aspect yet but happy to do that. and fwiw, i'm also not alone in this observation. I can at least remember 2 times in the last month that, other colleagues have cited this exact same benefit. e.g - a complicated algo that someone wrote 3 years ago, that's working well enough but has always had subtle bugs. over a 2 day workshop, we start first by writing a bunch of (meaningful) tests with an LLM. then ask the LLM about portions of the code and piecing together why a certain bit of logic existed or was written a certain way, add more tests to confirm working behavior, then start refactoring and changing the algo (also with an LLM). much of this is similar to how we'd do it without LLMs. but no one has bothered to improve/change it cause the time investment & ROI didn't make sense (let alone the cognitive burden in gathering context from git logs or old timers who have nuggets of context that could be pieced together). with LLMs a lot of that friction can be reduced.
• dearilos 1y ago
  Agreed. Tribal knowledge and communication is the biggest bottleneck. As soon as your team starts growing, you spend most of your time in communication and not writing code. This is what I’m working on fixing at wispbit.com
• intended 1y ago
  I predict that using LLMs is going to be a firing offense. There will be a 100 justifications for and against it, but in the end you are going to need junior devs. If said junior dev has not done the work, and an LLM has helped them, you are going to lose your hair walking through the code - every single time. So you will choose between doing the work yourself, hiring new devs, or making the environment you do your work in become predictable. We can argue that LLMs are massive piracy monstrosities, with huge amounts of public code in them, or that they are interfering with the ability of people to learn the culture of the company. The argument doesn't matter, because the reasoning being done here is motivated reasoning. You will not care how LLMs are kept out of the playing pen, you just care that they are out. So incentives will be structured to ensure that is the case. What will really be game set and match, will be when some massive disaster strikes because of bad code, and it can either directly or tangentially be linked to LLMs.
• linsomniac 1y ago
  That is true in some cases. However, there are many cases where writing the code IS the bottleneck. Experiments, trying different approaches, well defined code. Examples: This morning Claude Code built a browser-based app that visualizes 3.8M lines of JSON dumps of AWS infrastructure. Attention required by me: 15 minutes. Results: Reasonable for a 1-shot. A few weeks ago I had it build me a client/server app in multiple flavors from a well defined spec: async, threaded, and select, to see which one was the most clear and easy to maintain. A few days ago I gave it a 2K line python CLI tool and said "Build me a web interface to this CLI program". It nearly one-shotted it (probably would have if I had the playwright MCP configured). These are all things I never would have been able to pursue without the LLM tooling in the past because I just don't have time to write the code. There are definitely cases where the code is not the bottleneck, but those aren't the only cases.
  • shepherdjerred 1y ago
    I agree. Cursor has been amazing for me to write small test/validation scripts, write tedious code that wasn't very interesting to me, or perform some experiment. I can forget about the details and care more about architecture, how things connect, etc.
• alganet 1y ago
  The problem is managing complexity. That's the only simplification that makes sense and accounts for the different phenomena we see (solo developers doing amazing things exist, teams doing amazing things exist, amazing teachers exist, etc). There are many ways of doing it. If you understand the problem, and see a big ball of unecessary complexity rising, you get upset.
• nkotov 1y ago
  We're approaching a future where creativity will be the bottleneck, everything else is going to be abstracted away.
• btbuildem 1y ago
  > LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability. I'd argue that they're slowly changing that as well -- you can ask an LLM to "read" code, summarize / review / criticize it. At the least, it can help accelerate onboarding onto new / unfamiliar codebases.
• kpen11 1y ago
  Whether or not there was a claim that code _was_ the bottleneck, this raises some points that I've been talking over with people for a while now. Introducing a lever to suddenly produce more code faster creates an imbalance in the SDLC. If our review process was already a bottleneck, now that problem is even worse! If the review bottleneck was something we could tolerate/ignore before, that's no longer the case, we need to solve for it. No, that doesn't mean let some LLM review the code and ship it. CI/CD needs to get better and smarter. As a reviewer, I don't want to be on the lookout for obscure edge cases. I want to make sure my peer solved the problem in a way that makes sense for our team. CI/CD should take care of making sure the code style aligns with our policies, that new/updated tests provide enough coverage for the new/changed functionality, and that the feature actually works. The code expertise / shared context is another tough problem that needs solving, only highlighted by introducing a random graph of numbers generating the code. Leaning on that one engineer who has been on the team for 30 years and knows where all the deep dark secrets are was not a sustainable path even before coding agents. Having a markdown file that just says "component foo is under /foo. Run make foo to test it" was not documentation. The imbalance in the SDLC will light the fire under our collective asses to provide proper developer documentation and tooling for our codebases. I don't know what that looks like yet. Some teams are trying to have *good* markdown files that actually document where all the deep dark secrets are. These are doubly beneficial because coding agents can use those as well as your humans. But better markdown is probably a small step towards the real fix which we wont be able to live without in the near future. Anyway, great points brought up in the article. Coding agents aren't going away, so we need to solve this imbalance in the SDLC. Fight fire with fire!
  • kpen11 1y ago
    I'll be digging deeper on these ideas on a webinar on the 15th if this topic is interesting to you! https://dagger.io/webinar/agentic-ci https://dagger.io/webinar/agentic-ci
• teiferer 1y ago
  [dead]
• nahumba 1y ago
  I disagree. Writing code was a bottle neck in software engineering. Code review is for code that doesnt hold the standards. Debuging is for code not written well. Integration is needed when you dont take to acoount the properties of the different parts Specifications are the only missing part. And that is done through the question to the llm.
• skeeter2020 1y ago
  >> LLMs are powerful — but they don’t fix the fundamentals Sounds like we're (once again) rediscovering "No Silver Bullet".
• doug_durham 1y ago
  I think that the writer has it completely wrong. A lot of the "overhead" they describe came about precisely because software development was so precious and expensive. That will change now and LLMs can speed up the validation. Finally LLMs makes code reading and understanding much easier and faster which is the exact opposite of what the writer claims. It isn't going to be a work free utopia, but the write has the wrong framing of the situation.
• mhandley 1y ago
  I've spent the last few weeks writing a non-trivial distributed system using Codex (OpenAI's agentic coding system). I started by writing a design brief, and iterated with o3 to refine it so it was more complete and less ambiguous. Then I asked it to write a spec of all the messages - didn't like its first attempt, but iterated on it til I did like it. Then got it to write a project plan, and iterated on that. Only then did I start on the code. The purpose of all this is to provide it some context. It generated around 13K lines of Go for me in just over two weeks. I didn't previously speak Go, but its not hard to skimread to get the gist of its approach. I probably wrote about 100 lines, though I added and removed a lot of logging at various times to understand what was actually happening. I got it to write a lot of unit tests, so that coverage testing is very good. But I didn't actually pay a lot of attention to most of those tests on the first pass, because it generally got all the fine detail stuff exactly right on the first pass. So why all the tests? First, if something seems off, I have a place to start a deep dive. Second, it pins down the architecture so that functionality can't creep without me noticing that it is needing to change the unit tests. Some observations. - Coding this way is very effective - the new models almost never make fine detail mistakes. But I want to step it through chunks of new functionality at a size that I can at least skim and understand. So that 13K LoC is about 300 PRs. Otherwise I lose track of the big picture, and in this world, the big picture is my task. - Normally the big design decisions are separated by days of fine detail coding. Using codex means I get to make all those decisions nearly back-to-back. This is both good and bad. The experience is quite intense - mostly I found the fine-detail coding to be "therapeutic", but I don't get that anymore. But not needing to pay attention to the fine detail (at least most of the time), means I think I have a better picture in my head of the overall code structure. We only have so much attention at any time, and if I don't have to hold the details, I can pay attention to the more important things. - It's very good at writing integration tests quickly, so I write a lot more of them. These I do pay a lot of attention to. Its these tests that tell me if I got the design right, and if not, these are the place I start digging to understand what I need to change. - Because it takes 10-30m to come back with a response, I try to keep it working on around three tasks at a time. That takes some effort, as it does require come context switching, and effort to give it tasks that won't result in large merge conflicts. If it was faster, I would not bother to set multiple tasks in parallel. - Codex allows you to ask for multiple solutions. For simpler stuff, I've found asking for one is fine. For slightly more open questions, it's good to ask for multiple solutions, review them and decide which you prefer. - Just prompting it with "find a bug and suggest a fix" every now and then often shows up real bugs. Mostly they tend to be some form if internal inconsistency, where I'd changed my mind about part of the code, and the something elsewhere needed to be changed to be consistent. - I learned a lot about Go from it. If I'd been writing myself, my Go would have looked more like C++ which I'm very familiar with. But it wrote more idiomatic Go from the start, and I've learned along the way. - Any stock algorithm stuff it will one-shot. "Load this set of network links, build a graph from them, run dijkstra over the graph from this node, and tell me the histogram of how many equal-cost shortest paths there are to every other node." That sort of stuff it will one-shot. - It's much better than me about reasoning about concurrency. Though of course this is also one of Go's strengths. Now I don't have any experience of how good it would be for maintaining a much larger codebase, but for this sort of scale of utility, I'm very impressed with how effective it has been. Disclaimer: I work at OpenAI, but on networks, not AI.
• mdavid626 1y ago
  Slowly it’s getting time to become a goose farmer. Enough of this AI shit.
• starchild3001 1y ago
  X isn't the bottleneck. Y isn't the bottleneck. Z isn't the bottleneck. T ... Guess what X + Y + Z + T ... in aggregate are the bottleneck, and LLMs pretty much speed up the whole operation :) So pretty pointless and click-baity article & title, if you ask me.
• farzadmf 1y ago
  Wish the blog had an RSS feed
• strawberrisword 1y ago
  [dead]
• actinium226 1y ago
  It's always nice to look at history to parallels to modern conversations, and I think it's instructive to look back at the era when software jobs were getting outsourced to overseas. Even though the cost of generating code was cheaper, and the people on the other end can participate in meetings and all that, software is still primarily done in person. Even today, several years after the pandemic and the height of remote work, many tech companies are mandating in-office policies even for software workers. The point is that there's a human element to code that we can't even capture when working remotely with intelligent humans. LLMs will always be like a remote worker.
• deterministic 1y ago
  I completely agree with the author. I am only really more productive with LLM's when I have to use an API or tool I am not familiar with. Jasper Reports being the latest example. When it comes to what I do most, LLM's doesn't help much.
• rhubarbtree 1y ago
  I’m seeing this everywhere and it’s great to have it spelt out. “The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication” AI can dramatically speed up testing and code reviews. Generating unit tests is a major application of AI. Code reviews can be accelerated too: “please quickly explain what this code is doing” to give you a foothold; “please check this code for any obvious mistakes” enables you to quickly bounce if a new review will be needed. And better yet - the submitter can ask the AI to do that, and also to suggest refactoring that will make code review easier and faster for someone else. As for understand code and communicating it, well that is going to less and less necessary as the abstraction level we work at is lifted. This objection is just cope. It’s moving the goalposts because we’re scared AI is going to take out jobs. In truth, it will simply accelerate our work until we hit AGI. And at that point (which I think is probably a way off) we’ll have much greater concerns than the job market.
• nektro 1y ago
  yep!
• aiisahik 1y ago
  Lots of devs complaining about code quality and understandability here. I'm going to skip the obvious answer about how LLMs can actually improve code quality and reviewability and focus on a different argument: why engineers even care about code quality. Most code is not written as a work of art but as an important functional piece to achieve return on capital. Programmers get paid by companies to produce code. The payment ultimately is driven by expectation of a return on investment of the code. Ultimately business owners and owners do not really care about code quality as long as it can deliver on return on capital. There are plenty of profitable businesses run on spaghetti code and old technology. However, engineers realized that bad code resulted in costly downstream consequences including consequences that affected ROI. Tech debt had to be paid not just in developer hours but also dollars and cents. Thus this obsession with code quality, code reviews, and this current debate. Many including Andrew Ng at YC startup school recently are realizing that writing bad code is now a two way door instead of the one way door that it used to be. With LLMs you can deploy some bad code, realize it's bad, and rewrite that entire codebase tomorrow with near negligible cost. The fact that LLM can write some very very bad code is less important than the return on invested capital of that code especially when taking into account the speed at which that code can be fixed / completely re-written in the future, and especially when that in that future, LLMs will be even more capable than it is now. Here's my advice: give in the shitty code and merge it. Claude 6 will refactor all of it to your liking very soon.