14 ms·

Development speed is not a bottleneck

192 points by flail 1y ago

vessenes 1y ago
This is just so, so wrong. LLMs change the surface of what's "hard" to do in a coding exercise. Many a project has so much boiler plate, edge cases, etc. that months+ can be taken up dealing with what is ultimately a very boring activity. Add on time to assimilate APIs, bug test, etc. This stuff does matter.
- titzer 1y ago
  It reads like the author never debugged a program. Development speed is not just the time to write code, but also test, stabilize and debug it, with most of the latter being a risk that might cost you a lot much later. If your engineers have to take a two hour or two day or two week timeout to debug issues from weeks, months, or years back, then that really costs as development time. Vibe coding is going to make this so much worse; the tech debt of load-bearing code that no one really understands is going to be immense.
  - flail 1y ago
    Oh, development sure does mean the whole package. Architectural design, automated tests, coding, refactoring, code review and post-review changes, deployment, manual tests, etc. A question: what if all those activities are to build a feature that will harm user retention or a product no one wants? A follow-up question: what if we could have known that up front, or there was a simple way to learn that? Because so often we build stuff that shouldn't have been built in the first place (appalling startup success rate is probably a good enough statistical measure of that). And yes, there are ways to learn that we're building the wrong thing, other than building a fully-fledged version of it.
- vrighter 1y ago
  edge cases are exactly what I wouldn't trust an LLM with.
temporallobe 1y ago
About a decade ago, I was the sole developer for a special project. The code took 2 weeks to complete (a very simple Java servlet + JDBC app) but an entire year to actually deliver due to indecisive leadership, politics, and extremely overzealous security policies. By the time it was successfully deployed to prod, I had been chewed out by management countless times, who usually asked questions like “how on Earth can it take so long to do this one simple thing??”.
- vjvjvjvjghv 1y ago
  I see that a lot too. Something is super urgent, you work your ass off to deliver and then somebody sits on it for months before actually shipping. If ever.
  - skydhash 1y ago
    I don’t actually mind (because I won’t work my ass off). So when enthusiasm fizzle out, I just take a lot of notes (to onboard myself quickly) and shelve the project.
- latchkey 1y ago
  [deleted]
  - no_wizard 1y ago
    Not always simple to switch jobs unfortunately
- whstl 1y ago
  I saw two projects in a row in a German Fintech (the one that has AI in its name that forbids usage of AI) go exactly the same way. Two/three months to code everything ("It's maximum priority!"), about four to QA, and then about a year to deploy to individual country services by ops team. During test and deploy phases, the developers were just twiddling thumbs because ops refused to allow them access and product refused to take in new projects due to possibility of developers having to go back to code. It took the CEO to intervene and investigate the issues, and the CTO's college best friend that was running DevOps was demoted.
jajko 1y ago
The bigger and clunkier the corporation is, the slower the speed of deliveries. And actual development FWIW is somewhere in the range of 1-5% of it all. Sure, code sweat shops have very different % of above, but thats a completely different game altogether.
fosterfriends 1y ago
You can code PRs fast, but CI, review, merge, deployment, monitoring, all takes just as long as it did before. The inner loop is shrinking; the outer loop is the real bottleneck
thenanyu 1y ago
It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed. If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well. If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.
- trjordan 1y ago
  This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, implementing it isn't always the answer. Prototyping vs. production-quality implementation is different, even within that. But yeah, broadly, you need to test and validate as many _ideas_ as possible, in order take make as many correct _decisions_ as possible. That's one place I'm pretty bullish on AI: using it to explore/test ideas, which otherwise would have been too expensive. You can learn a ton by sending the AI off to research stuff (code, web search, your production logs, whatever), which lets you try more stuff. That genuinely tightens the feedback loop, and you go faster. I wrote a bit more about that here: https://tern.sh/blog/you-have-to-decide/ https://tern.sh/blog/you-have-to-decide/
  - 1y ago
BiteCode_dev 1y ago
Even if it were not a bottleneck, speed allow use cases you wouldn't consider before. I use Python differently because uv made many things faster, less costly. Stuff I used to do in bash are now in Python. Stuff I wouldn't do at all because 3rd party modules were an incompressible expense, now I do because the cost is low. Same with AI. Every week, there was a small tool I actively chose to not develop because I know that it would save less time by automating the thing than it would take coding it. E.G: I send regularly documents from my hard drive or forward mails to a specific email for accounting. It would be nice to be able to do those in one click. But dev a nautilus script or thunderbird extension to save max a minute a day doesn't make sense. Except now with claude code, it does. In a week, they paid off. And now I'm racking the minutes. Now each week, I'm getting a new tool that is not only saving me minutes, but also reducing context switching. Those turn into hours, which turn into days. These compounds. And of course, getting out a MVP, or a new feature demo out of the door quickly allows you to get feedback faster. In general, AI lets you get a shorter feedback loop. Trash bad concept sooner. Get crucial info faster. Those do speed up a project.
laurent_du 1y ago
I think development speed is merely tagging the correct causal factor which is expertise. I have witnessed development teams requiring weeks to change a single flag in a configuration flag? Were they slow? Well, yes, but I'd argue they were mostly clueless.
rekrsiv 1y ago
Development is often divided into 80% known unknowns and 20% unknown unknowns. AI can only help with one of those, and it's the one that takes the least amount of time to complete. Research and thinking is always going to be the bottleneck.
lordnacho 1y ago
I have very much started to re-evaluate whether I believe in this. I always thought something along the lines of "once you have solved it architecturally, typing it out is the least of your worries". But with LLMs I'm not so sure. I feel like I can skip the effort of typing, which is still effort, despite years of coding. I feel like I actually did end up spending quite a lot of time doing trivial nonsense like figuring out syntax errors and version mismatches. With an LLM I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things. This in turn means that I can test more things at the top architectural level. If I want to do an experiment, I don't feel a reluctance to actually do it, since I now don't need to concentrate on it, rather I'm just guiding the AI. I can even do multiple such explorations at once.
- kasey_junk 1y ago
  This echoes my feelings as well. I’d go further, I’ve long said that the real problem in software is verification, but my actions didn’t match that because I’d spend less time on that than code creation. With the llm I really can spend most of my time on the verification problem.
- theptip 1y ago
  Absolutely, my experience too. I think the bleeding edge models are very good at “idea infill”. Depending on your subject matter you might only need an idea or two per 100loc generated. So much of what I used to do turns out to be grunt work that was simply pattern matching on simple heuristics, but I can churn out 5-10 good ideas per hour it seems, so I’m definitely rate limited on coding. Similar to your comment on architectural experiments, one thing I have been observing is that the critical path doesn’t go 10x faster, but by multiplexing small incidental ideas I can get a lot more done. Eg “it would be nice if we had a new set of integration tests that stub this API in some slightly tedious way, go build that”.
marginalia_nu 1y ago
I would reconcile the seeming paradox that AI-assisted coding produces more code faster, yet doesn't seem to produce products or features much faster by considering that AI code generation and in particular CoPilot-style code suggestions means the programmer is constantly invalidating and re-building their mental model of the code, which is not only slow but exhausting (and a tired programmer makes more errors in judgement). It's basically the wetware equivalent of page thrashing. My experience is that I write better code faster by turning off the AI assistants and trying to configure the IDE to as best possible produce deterministic and fast suggestions, that way they become a rapid shorthand. This makes for a fast way of writing code that doesn't lead to mental model thrashing, since the model can be updated incrementally as I go. The exception is using LLMs to straight up generate a prototype that can be refined. That also works pretty well, and largely avoids the expensive exchanges of information back and forth between human and machine.
- bckr 1y ago
  I’m moving this way as well after about 6 months of generating 95% of my code with Cursor/Claude. My new paradigm is something like: - write a few paragraphs about what is needed - have the bot take in the context and produce a prototype solution outside of the main application - have the bot describe main integration challenges - do that integration myself — although I’m still somewhat lazy about this and keep trying to have the bot do it after the above steps; it seems to only have maybe 50% success rate - obviously test thoroughly
- flail 1y ago
  Whenever a development effort involves a lot of AI-generated code, the nature of the task shifts from typing-heavy to code-review-heavy. Cognitively, these are very different tasks. With the former, we actively drive technical decisions (decide on architecture, implementation details, even naming). The latter offers all these decisions made, and we first need to untangle them all before we can scrutinize the details. What's more, often AI-generated code results in bigger PRs, which again adds to the cognitive load. And some developers fall into a rabbit hole of starting another thing while they wait for their agent to produce the code. Adding context switching to an already taxing challenge basically fries brains. There's no way such a code review to consistently catch the issues. I see how development teams define health routines around working with generated code. Especially around limiting context switching. But also retaking tasks to be made by hand.
ardit33 1y ago
lol.... development speed and quality are both the bottleneck my dude. But if you have enough speed, you can fix quality issues as you are able to test and fix things faster. You have even CEO of car companies that get fired because they mess this up. Or even the Sonos company lost a lot of value, and got their CEO fired because they messed up and can't fix it in time. Speed is not everything. Developing the right features (what users want) and Quality are the most important things, but development speed allows you to test features and fix things fast and course correct.
- speed_spread 1y ago
  Car companies cannot figure what to develop and how to develop it. They could develop 1000% faster and would still get it wrong. Mostly because they see software as a cheap alternative to metal and rubber and developers as degenerate primadonnas - i.e. not true engineers. Sonos decided they wanted to centralize their architecture so they could tap into it to make extra surveillance money. They trashed things that worked perfectly and replaced them with a cloudshit architecture that nobody asked for and that _cannot_ deliver the same low-latency, quality experience as before. They could have developed things 1000% faster, they would have just drove a cliff sooner. Even if people could write apps instantly, nothing would prevent them for being stupid and greedy.
123sereusername 1y ago
[dead]
zduoduo 1y ago
Yeah, “development speed” is almost never the real blocker. I’ve worked on teams where folks shipped code at lightning speed… straight into the wrong direction. Turns out it’s way slower to undo that than to just move carefully with clarity.
witnessme 1y ago
How fast can you react to the learning you have from the market, that's the bottleneck. And yes, the development is the big chunk of that reaction time.
ciconia 1y ago
The article sort of glosses over this, but to me the real question is delivering value over the long run. This takes patience and tenacity not just from developers but also from management. Making a product that lasts and that evolves and that delivers for your clients is definitely a lot more challenging (and finally rewarding) than vibe-coding an MVP in a couple of weeks. I have the impression that in that regard AI coding tools are quite inadequate and don't really deliver the value they purport to.
- flail 1y ago
  That's just another great vantage point to consider when looking at product development. Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing. And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche. At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases. In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.
mlinsey 1y ago
Validation is definitely the bottleneck, if you make all your product decisions through a/b tests and wait for a statistically significant result for each feature. But there are people with great product taste who can know by trying a product whether it meets a real user need - some of these are early-adopter customers, sometimes they are great designers, sometimes PMs. And they really do need to try a product (or prototype) to really know whether it works. I was always frustrated as a junior engineer when the PM would design a feature in a written spec, we would implement it, and then when trying it out before launch, they would want to totally redesign it, often in ways which required either terrible hacks or significant technical design changes to meet the new requirements. But after 15 years of seeing some great ideas on paper fall flat with our users, and noticing that truly exceptional product people could tell exactly what was wrong after the feature was built but before it was released to users, I learned to be flexible about those sorts of rewrites. And it’s exactly that sort of thing that vibecoding can accelerate
- smelendez 1y ago
  It's interesting how frustrating it can feel to backtrack, even when it's the right move I definitely have felt this too. Also, in the past I've done interactive maps and charts for different media organizations, and people would often debate for a considerable amount of time whether to, for example, make a bar or line chart (the actual questions and visualizations themselves were usually more sophisticated). I remember occasionally suggesting prototyping both options and trying them out, and intuitively that usually struck people as impractical, even though it would often take less time than the discussions and yield more concrete results.
- flail 1y ago
  We have this saying: Our clients always know what they want. Until they get it. Then they know they wanted something different. And don't take that as a complaint. It's a basic behavioral observation. What we say we do is different from what we really do. By the same token, what we say we want is different from what we really want. At a risk of being a bit sarcastic: we say we want regular exercise to keep fit, but we really want doomscrolling on a sofa with a beer in hand. In the product development context, we have a very different attitude towards an imagined (hell, even wireframed) solution than an actual working piece of software. So it's kinda obvious we can't get it right on the first attempt. We can be working toward the right direction, and many product teams don't even do that. For them, development speed is only a clock counting time remaining before VCs pull the plug.
wglb 1y ago
Development speed has been a bottleneck in every major product development effort that I have been involved in. From a realtime medical data collection application where president and VP are drumming their fingers on the desk waiting for development to be finished. Writing a compiler at Sycor, there were teams waiting for us to finish our development. We were successful, being about an order of magnitude faster than the effort we replaced. And just because google cancels products doesn't suggest anything about development speed. If I were an LLM advocate (having much fun currently with gemini), I would let the criticism roll and make book using LLMs.
- flail 1y ago
  Oh, I agree that in many companies, internally, we create perceptions that development is, indeed, THE bottleneck. VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare. And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a pure waste. Some other parts were actually harmful. They frustrated users, drove key metrics down, or have you. They are worse than waste. But no one cared to check. Good product people, and there are scarcely few of them, would follow up with validation on what worked and what did not. They would argue against "major" releases whenever possible. And seriously, if Amazon can avoid major releases, almost anyone could. Suddenly, we might flip the script and have a VP of Product not asking "when will it be done?" but rather trying to figure out what the next most sensible experiments are.
  - wglb 1y ago
    Disagree. My experience is that it is a measurable fact and not a created perception. And few of us can usefully compare what we do with what amazon google Facebook or other giants do. Good luck on flipping their script. Meanwhile I’ll be over here making book
sega_sai 1y ago
I completely disagree. As a scientist who does a lot of coding, the modern LLM tools give me ability to code something which previously I could not afford, because I simply did not have time for it. Now if I have an idea, I may be able to test it in an hour of tinkering with claude/gemini. I could technically still code it myself, but in some cases that would require maybe a day of work -- and I simply don't have that.
- flail 1y ago
  You mention one fabulous application of AI-supported coding that the article didn't touch upon. It's anything where the target customer group is me. All sorts of automation, pet projects, and serious stuff that improves research, too. The context of the article is product development, with a bias toward the commercial part of the ecosystem. And of course, as any picture painted with broad strokes, some generalizations were inevitable. As a scientist, you definitely are familiar with the weight (or lack thereof) of anecdotal evidence. Unless the claim is "it can never work" or "it always works," my individual experience is just that--an individual experience.
- patrulek 1y ago
  Im not a scientist, just a freelancer (kind of) and its similar for me. I know probably only 2 langauges fluently enough that i could write in them without constantly checking for syntax/docs, but over my whole programming journey i got to know multiple languages with different syntaxes, coding styles and patterns, so i can easily read code written in multiple languages and know whether given code will do what i want (and even if i wouldn't, LLM can explain the code for me and in the worst case send me to the documentation to validate it by myself). Asking LLM for a code and then read/review it is a huge speed up for me in a lot of cases comparing to when i would need to write the same thing by myself (but i agree it may not work well in a big/complex systems... yet).
inerte 1y ago
Most software projects don't even do A/B tests. A lot of them don't need, it's just what someone wants to ship. Another set can't even get to the sample size required. But fine, let's take the subset of features / projects that can be tested or somehow validated. In my experience (having worked for 13+ years on companies that prefer to A/B almost everything), more than half of the tests fail. People initially might think the solution is to have better ideas, cook them more, do better analysis. That's usually wrong. I've seen PHDs with 20+ years of experience in a given industry (Search) launch experiments and they still fail. The solution is to have some sort of "just enough" analysis like user studies, intuition, and business needs, and launch as fast and as many as you can. Therefore, development speed is A bottleneck (there's no Silver Bullet so it's not THE bottleneck).
dismalaf 1y ago
Title feels like a bait and switch. Development speed absolutely is a bottleneck. But coding speed? Like, typing? Yeah, I can definitely type faster than I can think about code, or anything really (typing at 100wpm is a fun party trick but not super useful in the end). Many times over... Even single finger typers who peck at the keyboard probably can, auto-complete has existed for a long time...
kerblang 1y ago
Journalists & executives see you as a sort of savant who spends all your time encoding & decoding the little bits and bytes - mostly a construction worker. They correctly recognize that we ought to be able to build some sort of robot that does this for you - why do it by hand? They don't understand that this AI was built decades ago and has been improved on several times over: Compilers & Interpreters. Furthermore, you don't need billion-dollar neural-network supercomputers, just a vanilla laptop. It's because of how you talk about the job, though. We automate every other kind of "coding" - why can't we automate yours?
uhura 1y ago
This kind of stance cannot be made without properly setting the context for the software. It is very clear that different software backgrounds have different needs a different development strategies that are more efficient. LLMs are a tool that added a new dimension to explore. While I haven't like many felt actual gains, others are finding, and time will allow us to better judge if those can lead to long term impacts in the economy. Just based on what I've been reading and experiencing: - Short term POCs can reach validation stage faster. - Mature cloud software needs a lot of extra tooling (LLMs don't understand the codebase, lack of places to derive good context from, and so on). - Anything in between for cloud seems to be a hit or miss, where people are mostly trading first iteration time for more refactoring later down the line. From another perspective, areas of software where things are a lot more about numbers (cpu time, memory consumption, and so on), may benefit a lot from faster development/coding as the validation phase is either shorter or can be executed in parallel. The key reality here is that I've been observing higher expectations for deliveries without a proof that we actually got better at coding in general. Which means that sacrifices are being made somewhere.
- flail 1y ago
  My experience correlates with this assessment. The closer we are toward prototyping, the bigger leverage we gain from quickly generated swaths of code. It's simply because we don't need to care about all the quality guardrails. After all, it's a prototype. With a more complex code base (and a less popular tech stack), the perceived gains quickly diminish. Beyond a certain level of tech debt, AI-generated code is utterly useless. It's no surprise that we see people who vibe-coded their products with no technical knowledge whatsoever, and now they call professional engineers to untangle the mess. A software agency I know well responded to the rise of AI somewhere between the lines of "Now, we'll have plenty of work to clean all that mess!" Admittedly, they always specialized in complex/rescue engineering gigs. However, the "development as a bottleneck" discussion was set here in a broader context. It's not only how efficiently we are able to deliver bits of functionality, but primarily whether we should be building these things in the first place. Equally for early-stage startups and established products alike, so much of features are built because someone said so. At the end of the day, they don't deliver any value (if we're lucky) or are plain harmful (if we're out of luck). In such cases, it would have been better if developers actually sipped coffee and read Hacker News rather than coded/developed/engineered stuff.
BinaryIgor 1y ago
Interesting article, but a slightly misleading title. Other than that the discovery process of what you should build is the hardest and the costliest part, the main conclusion from the article seems to be that if you outsource the first iterations to AI via vibe-coding, you will have much harder time changing and evolving it from there (iterating); to this, I agree
IshKebab 1y ago
This is like he's picked a clickbait position, ignored how very obviously wrong it is, and argued for it as best he can. Nice try, but it's still obviously wrong.
m0llusk 1y ago
Many here are restricting the domain to engineering which makes the real bottlenecks disappear. A good reminder of the larger context is Ralph Grabowski's Marketing to Engineering ratio. Companies that spend less on marketing that engineering tend not to endure. Companies that do endure tend to spend over double and closer to ten times as much on marketing as engineering. So the real bottlenecks in development are not centered on engineering, but the coordination of engineering and marketing in order to solve problems that matter to customers in ways that customers can be aware of and assign value to. Go ahead and code as much as you want. Unless you can communicate the utility of that code to a paying customer it has no value or relevance.
estimator7292 1y ago
Developers would gain a lot more speed than what LLMs offer if Microsoft would just fucking stop using >50% of the CPU watching your compiler for... something? Nobody wants to believe it, but just try compiling C++ on Windows and again in a Linux VM. Linux in a VM on the same host compiles at least twice as fast. It's insanity. I tried a script that rsync's the project files to my server from 2013, runs the build and rsync's the artifacts back. Running the build on a Xeon 2500 is still far faster with Linux than windows on my two year old i9. Even with the overhead of sending binaries over the internet. Absolutely disgusting.
simpleshadow 1y ago
that hn can have an article stating "development speed is not a bottleneck" is indicative of the fact that development speed is a bottleneck
angarg12 1y ago
The argument that the article uses to critique AI coding is that coding is not the bottleneck, instead the testing and validation of ideas is. This is a first-degree smart argument. It presents a seemingly non-obvious idea that makes sense in retrospect. However I happen to work at the experimentation team of a hyperscaler so I have a different perspective. First, we aren't always saturating all of the potential experiments we could be running. The reasons are different, but essentially it takes time and effort to build those experimental features. If that cost trended to 0, we could make sure to have a queue of experiments deep enough. Also in our side we need to do development work to support new features and products. We have a backlog long enough to keep us perpetually busy. If dev cost trended to 0, we could always be ready to provide our customers what they need. Speaking of new products, each one our company comes up with comes with extra effort to support in our side, and yet more effort to produce dozens of AB test to validate new functionality. This is not talking about ongoing maintenance effort. Bugfixes, upgrades etc. take a non-trivial amount of effort to keep up. And this is only inside our little experimentation team. What about security, reliability, scalability, efficiency... it makes me wonder if OP has experience running products at scale. Instead I'd like to think that dropping the cost of development by orders of magnitude changes the equation of how we create products.
tomekrusilko 1y ago
[dead]
sylware 1y ago
For tons of software out there, but not all, development time is minuscule compared to the life cycle.
j-pb 1y ago
What these LLMs enable is fixing the foundations. If you considered writing a novel database, operating system, or other foundational piece of software two years ago, you had to be mad. Now you still do, but at least you got a chance. I can highly recommend these talks to get your eyes slightly opened to how stuck we are in a local minima. https://vimeo.com/71278954 https://vimeo.com/71278954 https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
HumblyTossed 1y ago
You have the unbelievably productive programmers - we all know their names, we use the code they wrote every day. Then you have the programmers who want to be there and will try everything they can to be there - except gain depth of knowledge. They tend to be shallow programmers. If you give them a task and spell it out, they can knock out code for it at a really good pace and wow upper management. But they will always lack the ability to take a task not spelled out and complete it. Vibe-coding is like sugar and crack mixed together for these people.
- throwaway-18 1y ago
  The difference between Software Engineers (or Developers) vs Programmers; with the latter designation being a stretch for some.
  - hombre_fatal 1y ago
    I think we should we put this title-based distinction to rest. Whether you call yourself an engineer, developer, programmer, or even a coder is mostly a localized thing, not an evaluation of expertise. We're confusing everyone when we pretend a title reflects how good we are at the craft, especially titles we already use to refer to ourselves without judgement. At least use script kiddie or something.
    - bob1029 1y ago
      In my local world: Writing code to specification is programming. Writing the specification is engineering.
- no_wizard 1y ago
  It’s infecting expectations I’ve noticed as well. The thing LLM coding tools expose very plainly if someone wasn’t already aware is that management would rather ship with bugs or missing features - no matter how many - as long as the “happy path” works. The vibe coders can deliver on happy path results pretty fast but I already have seen within 2 months it starts to fall apart quick and has to be extensively refactored which ends up ultimately taking more time than if it was done with quality in mind in the first place And supposedly the free market makes companies “efficient and logical”
goalieca 1y ago
Development is always a bottleneck. Writing lines of code usually isn’t. I end up pumping out more leetcode during an interview than I do during a week or two on real products. No one has meaningfully measured lines of code as a metric of productivity since my career began in the mid-2000.
- khazhoux 1y ago
  On the other hand, there’s tons of people here on HN who will claim that there’s zero connection between lines of code written and developer productivity. Obviously, deleting bad/unused code is good. And obviously, some tricky bugs are fixed in one line. But you can’t build something new without some (usually, very many) lines of code. No code -> no software.
  - goalieca 1y ago
    What would be the function mapping lines of code to "value" look like. Most agile teams aim to deliver "value" these days. We can't put a number of value. We most certainly can't say on average that adding a single line of code adds 0.01 units of value for a certain project.
    - khazhoux 1y ago
      > We most certainly can't say on average that adding a single line of code adds 0.01 units of value for Certainly there’s no simple F(num_lines_changed) value function. There are many other parameters. But to suggest, as many here somehow do, that lines of code touched is independent to effective development, is plain ludicrous.

192 points by flail 1y ago

This is just so, so wrong. LLMs change the surface of what's "hard" to do in a coding exercise. Many a project has so much boiler plate, edge cases, etc. that months+ can be taken up dealing with what is ultimately a very boring activity. Add on time to assimilate APIs, bug test, etc. This stuff does matter.

titzer 1y ago
It reads like the author never debugged a program. Development speed is not just the time to write code, but also test, stabilize and debug it, with most of the latter being a risk that might cost you a lot much later. If your engineers have to take a two hour or two day or two week timeout to debug issues from weeks, months, or years back, then that really costs as development time. Vibe coding is going to make this so much worse; the tech debt of load-bearing code that no one really understands is going to be immense.
- flail 1y ago
  Oh, development sure does mean the whole package. Architectural design, automated tests, coding, refactoring, code review and post-review changes, deployment, manual tests, etc. A question: what if all those activities are to build a feature that will harm user retention or a product no one wants? A follow-up question: what if we could have known that up front, or there was a simple way to learn that? Because so often we build stuff that shouldn't have been built in the first place (appalling startup success rate is probably a good enough statistical measure of that). And yes, there are ways to learn that we're building the wrong thing, other than building a fully-fledged version of it.
vrighter 1y ago
edge cases are exactly what I wouldn't trust an LLM with.

temporallobe 1y ago

About a decade ago, I was the sole developer for a special project. The code took 2 weeks to complete (a very simple Java servlet + JDBC app) but an entire year to actually deliver due to indecisive leadership, politics, and extremely overzealous security policies. By the time it was successfully deployed to prod, I had been chewed out by management countless times, who usually asked questions like “how on Earth can it take so long to do this one simple thing??”.

vjvjvjvjghv 1y ago
I see that a lot too. Something is super urgent, you work your ass off to deliver and then somebody sits on it for months before actually shipping. If ever.
- skydhash 1y ago
  I don’t actually mind (because I won’t work my ass off). So when enthusiasm fizzle out, I just take a lot of notes (to onboard myself quickly) and shelve the project.
latchkey 1y ago
[deleted]
- no_wizard 1y ago
  Not always simple to switch jobs unfortunately
whstl 1y ago
I saw two projects in a row in a German Fintech (the one that has AI in its name that forbids usage of AI) go exactly the same way. Two/three months to code everything ("It's maximum priority!"), about four to QA, and then about a year to deploy to individual country services by ops team. During test and deploy phases, the developers were just twiddling thumbs because ops refused to allow them access and product refused to take in new projects due to possibility of developers having to go back to code. It took the CEO to intervene and investigate the issues, and the CTO's college best friend that was running DevOps was demoted.

jajko 1y ago

The bigger and clunkier the corporation is, the slower the speed of deliveries. And actual development FWIW is somewhere in the range of 1-5% of it all. Sure, code sweat shops have very different % of above, but thats a completely different game altogether.

fosterfriends 1y ago

You can code PRs fast, but CI, review, merge, deployment, monitoring, all takes just as long as it did before. The inner loop is shrinking; the outer loop is the real bottleneck

thenanyu 1y ago

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed. If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well. If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.

trjordan 1y ago
This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, implementing it isn't always the answer. Prototyping vs. production-quality implementation is different, even within that. But yeah, broadly, you need to test and validate as many _ideas_ as possible, in order take make as many correct _decisions_ as possible. That's one place I'm pretty bullish on AI: using it to explore/test ideas, which otherwise would have been too expensive. You can learn a ton by sending the AI off to research stuff (code, web search, your production logs, whatever), which lets you try more stuff. That genuinely tightens the feedback loop, and you go faster. I wrote a bit more about that here: https://tern.sh/blog/you-have-to-decide/ https://tern.sh/blog/you-have-to-decide/
- 1y ago

BiteCode_dev 1y ago

Even if it were not a bottleneck, speed allow use cases you wouldn't consider before. I use Python differently because uv made many things faster, less costly. Stuff I used to do in bash are now in Python. Stuff I wouldn't do at all because 3rd party modules were an incompressible expense, now I do because the cost is low. Same with AI. Every week, there was a small tool I actively chose to not develop because I know that it would save less time by automating the thing than it would take coding it. E.G: I send regularly documents from my hard drive or forward mails to a specific email for accounting. It would be nice to be able to do those in one click. But dev a nautilus script or thunderbird extension to save max a minute a day doesn't make sense. Except now with claude code, it does. In a week, they paid off. And now I'm racking the minutes. Now each week, I'm getting a new tool that is not only saving me minutes, but also reducing context switching. Those turn into hours, which turn into days. These compounds. And of course, getting out a MVP, or a new feature demo out of the door quickly allows you to get feedback faster. In general, AI lets you get a shorter feedback loop. Trash bad concept sooner. Get crucial info faster. Those do speed up a project.

laurent_du 1y ago

I think development speed is merely tagging the correct causal factor which is expertise. I have witnessed development teams requiring weeks to change a single flag in a configuration flag? Were they slow? Well, yes, but I'd argue they were mostly clueless.

rekrsiv 1y ago

Development is often divided into 80% known unknowns and 20% unknown unknowns. AI can only help with one of those, and it's the one that takes the least amount of time to complete. Research and thinking is always going to be the bottleneck.

lordnacho 1y ago

I have very much started to re-evaluate whether I believe in this. I always thought something along the lines of "once you have solved it architecturally, typing it out is the least of your worries". But with LLMs I'm not so sure. I feel like I can skip the effort of typing, which is still effort, despite years of coding. I feel like I actually did end up spending quite a lot of time doing trivial nonsense like figuring out syntax errors and version mismatches. With an LLM I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things. This in turn means that I can test more things at the top architectural level. If I want to do an experiment, I don't feel a reluctance to actually do it, since I now don't need to concentrate on it, rather I'm just guiding the AI. I can even do multiple such explorations at once.

kasey_junk 1y ago
This echoes my feelings as well. I’d go further, I’ve long said that the real problem in software is verification, but my actions didn’t match that because I’d spend less time on that than code creation. With the llm I really can spend most of my time on the verification problem.
theptip 1y ago
Absolutely, my experience too. I think the bleeding edge models are very good at “idea infill”. Depending on your subject matter you might only need an idea or two per 100loc generated. So much of what I used to do turns out to be grunt work that was simply pattern matching on simple heuristics, but I can churn out 5-10 good ideas per hour it seems, so I’m definitely rate limited on coding. Similar to your comment on architectural experiments, one thing I have been observing is that the critical path doesn’t go 10x faster, but by multiplexing small incidental ideas I can get a lot more done. Eg “it would be nice if we had a new set of integration tests that stub this API in some slightly tedious way, go build that”.

marginalia_nu 1y ago

I would reconcile the seeming paradox that AI-assisted coding produces more code faster, yet doesn't seem to produce products or features much faster by considering that AI code generation and in particular CoPilot-style code suggestions means the programmer is constantly invalidating and re-building their mental model of the code, which is not only slow but exhausting (and a tired programmer makes more errors in judgement). It's basically the wetware equivalent of page thrashing. My experience is that I write better code faster by turning off the AI assistants and trying to configure the IDE to as best possible produce deterministic and fast suggestions, that way they become a rapid shorthand. This makes for a fast way of writing code that doesn't lead to mental model thrashing, since the model can be updated incrementally as I go. The exception is using LLMs to straight up generate a prototype that can be refined. That also works pretty well, and largely avoids the expensive exchanges of information back and forth between human and machine.

bckr 1y ago
I’m moving this way as well after about 6 months of generating 95% of my code with Cursor/Claude. My new paradigm is something like: - write a few paragraphs about what is needed - have the bot take in the context and produce a prototype solution outside of the main application - have the bot describe main integration challenges - do that integration myself — although I’m still somewhat lazy about this and keep trying to have the bot do it after the above steps; it seems to only have maybe 50% success rate - obviously test thoroughly
flail 1y ago
Whenever a development effort involves a lot of AI-generated code, the nature of the task shifts from typing-heavy to code-review-heavy. Cognitively, these are very different tasks. With the former, we actively drive technical decisions (decide on architecture, implementation details, even naming). The latter offers all these decisions made, and we first need to untangle them all before we can scrutinize the details. What's more, often AI-generated code results in bigger PRs, which again adds to the cognitive load. And some developers fall into a rabbit hole of starting another thing while they wait for their agent to produce the code. Adding context switching to an already taxing challenge basically fries brains. There's no way such a code review to consistently catch the issues. I see how development teams define health routines around working with generated code. Especially around limiting context switching. But also retaking tasks to be made by hand.

ardit33 1y ago

lol.... development speed and quality are both the bottleneck my dude. But if you have enough speed, you can fix quality issues as you are able to test and fix things faster. You have even CEO of car companies that get fired because they mess this up. Or even the Sonos company lost a lot of value, and got their CEO fired because they messed up and can't fix it in time. Speed is not everything. Developing the right features (what users want) and Quality are the most important things, but development speed allows you to test features and fix things fast and course correct.

speed_spread 1y ago
Car companies cannot figure what to develop and how to develop it. They could develop 1000% faster and would still get it wrong. Mostly because they see software as a cheap alternative to metal and rubber and developers as degenerate primadonnas - i.e. not true engineers. Sonos decided they wanted to centralize their architecture so they could tap into it to make extra surveillance money. They trashed things that worked perfectly and replaced them with a cloudshit architecture that nobody asked for and that _cannot_ deliver the same low-latency, quality experience as before. They could have developed things 1000% faster, they would have just drove a cliff sooner. Even if people could write apps instantly, nothing would prevent them for being stupid and greedy.

123sereusername 1y ago

[dead]

zduoduo 1y ago

Yeah, “development speed” is almost never the real blocker. I’ve worked on teams where folks shipped code at lightning speed… straight into the wrong direction. Turns out it’s way slower to undo that than to just move carefully with clarity.

witnessme 1y ago

How fast can you react to the learning you have from the market, that's the bottleneck. And yes, the development is the big chunk of that reaction time.

ciconia 1y ago

The article sort of glosses over this, but to me the real question is delivering value over the long run. This takes patience and tenacity not just from developers but also from management. Making a product that lasts and that evolves and that delivers for your clients is definitely a lot more challenging (and finally rewarding) than vibe-coding an MVP in a couple of weeks. I have the impression that in that regard AI coding tools are quite inadequate and don't really deliver the value they purport to.

flail 1y ago
That's just another great vantage point to consider when looking at product development. Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing. And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche. At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases. In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.

mlinsey 1y ago

Validation is definitely the bottleneck, if you make all your product decisions through a/b tests and wait for a statistically significant result for each feature. But there are people with great product taste who can know by trying a product whether it meets a real user need - some of these are early-adopter customers, sometimes they are great designers, sometimes PMs. And they really do need to try a product (or prototype) to really know whether it works. I was always frustrated as a junior engineer when the PM would design a feature in a written spec, we would implement it, and then when trying it out before launch, they would want to totally redesign it, often in ways which required either terrible hacks or significant technical design changes to meet the new requirements. But after 15 years of seeing some great ideas on paper fall flat with our users, and noticing that truly exceptional product people could tell exactly what was wrong after the feature was built but before it was released to users, I learned to be flexible about those sorts of rewrites. And it’s exactly that sort of thing that vibecoding can accelerate

smelendez 1y ago
It's interesting how frustrating it can feel to backtrack, even when it's the right move I definitely have felt this too. Also, in the past I've done interactive maps and charts for different media organizations, and people would often debate for a considerable amount of time whether to, for example, make a bar or line chart (the actual questions and visualizations themselves were usually more sophisticated). I remember occasionally suggesting prototyping both options and trying them out, and intuitively that usually struck people as impractical, even though it would often take less time than the discussions and yield more concrete results.
flail 1y ago
We have this saying: Our clients always know what they want. Until they get it. Then they know they wanted something different. And don't take that as a complaint. It's a basic behavioral observation. What we say we do is different from what we really do. By the same token, what we say we want is different from what we really want. At a risk of being a bit sarcastic: we say we want regular exercise to keep fit, but we really want doomscrolling on a sofa with a beer in hand. In the product development context, we have a very different attitude towards an imagined (hell, even wireframed) solution than an actual working piece of software. So it's kinda obvious we can't get it right on the first attempt. We can be working toward the right direction, and many product teams don't even do that. For them, development speed is only a clock counting time remaining before VCs pull the plug.

wglb 1y ago

Development speed has been a bottleneck in every major product development effort that I have been involved in. From a realtime medical data collection application where president and VP are drumming their fingers on the desk waiting for development to be finished. Writing a compiler at Sycor, there were teams waiting for us to finish our development. We were successful, being about an order of magnitude faster than the effort we replaced. And just because google cancels products doesn't suggest anything about development speed. If I were an LLM advocate (having much fun currently with gemini), I would let the criticism roll and make book using LLMs.

flail 1y ago
Oh, I agree that in many companies, internally, we create perceptions that development is, indeed, THE bottleneck. VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare. And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a pure waste. Some other parts were actually harmful. They frustrated users, drove key metrics down, or have you. They are worse than waste. But no one cared to check. Good product people, and there are scarcely few of them, would follow up with validation on what worked and what did not. They would argue against "major" releases whenever possible. And seriously, if Amazon can avoid major releases, almost anyone could. Suddenly, we might flip the script and have a VP of Product not asking "when will it be done?" but rather trying to figure out what the next most sensible experiments are.
- wglb 1y ago
  Disagree. My experience is that it is a measurable fact and not a created perception. And few of us can usefully compare what we do with what amazon google Facebook or other giants do. Good luck on flipping their script. Meanwhile I’ll be over here making book

sega_sai 1y ago

I completely disagree. As a scientist who does a lot of coding, the modern LLM tools give me ability to code something which previously I could not afford, because I simply did not have time for it. Now if I have an idea, I may be able to test it in an hour of tinkering with claude/gemini. I could technically still code it myself, but in some cases that would require maybe a day of work -- and I simply don't have that.

flail 1y ago
You mention one fabulous application of AI-supported coding that the article didn't touch upon. It's anything where the target customer group is me. All sorts of automation, pet projects, and serious stuff that improves research, too. The context of the article is product development, with a bias toward the commercial part of the ecosystem. And of course, as any picture painted with broad strokes, some generalizations were inevitable. As a scientist, you definitely are familiar with the weight (or lack thereof) of anecdotal evidence. Unless the claim is "it can never work" or "it always works," my individual experience is just that--an individual experience.
patrulek 1y ago
Im not a scientist, just a freelancer (kind of) and its similar for me. I know probably only 2 langauges fluently enough that i could write in them without constantly checking for syntax/docs, but over my whole programming journey i got to know multiple languages with different syntaxes, coding styles and patterns, so i can easily read code written in multiple languages and know whether given code will do what i want (and even if i wouldn't, LLM can explain the code for me and in the worst case send me to the documentation to validate it by myself). Asking LLM for a code and then read/review it is a huge speed up for me in a lot of cases comparing to when i would need to write the same thing by myself (but i agree it may not work well in a big/complex systems... yet).

inerte 1y ago

Most software projects don't even do A/B tests. A lot of them don't need, it's just what someone wants to ship. Another set can't even get to the sample size required. But fine, let's take the subset of features / projects that can be tested or somehow validated. In my experience (having worked for 13+ years on companies that prefer to A/B almost everything), more than half of the tests fail. People initially might think the solution is to have better ideas, cook them more, do better analysis. That's usually wrong. I've seen PHDs with 20+ years of experience in a given industry (Search) launch experiments and they still fail. The solution is to have some sort of "just enough" analysis like user studies, intuition, and business needs, and launch as fast and as many as you can. Therefore, development speed is A bottleneck (there's no Silver Bullet so it's not THE bottleneck).

dismalaf 1y ago

Title feels like a bait and switch. Development speed absolutely is a bottleneck. But coding speed? Like, typing? Yeah, I can definitely type faster than I can think about code, or anything really (typing at 100wpm is a fun party trick but not super useful in the end). Many times over... Even single finger typers who peck at the keyboard probably can, auto-complete has existed for a long time...

kerblang 1y ago

Journalists & executives see you as a sort of savant who spends all your time encoding & decoding the little bits and bytes - mostly a construction worker. They correctly recognize that we ought to be able to build some sort of robot that does this for you - why do it by hand? They don't understand that this AI was built decades ago and has been improved on several times over: Compilers & Interpreters. Furthermore, you don't need billion-dollar neural-network supercomputers, just a vanilla laptop. It's because of how you talk about the job, though. We automate every other kind of "coding" - why can't we automate yours?

uhura 1y ago

This kind of stance cannot be made without properly setting the context for the software. It is very clear that different software backgrounds have different needs a different development strategies that are more efficient. LLMs are a tool that added a new dimension to explore. While I haven't like many felt actual gains, others are finding, and time will allow us to better judge if those can lead to long term impacts in the economy. Just based on what I've been reading and experiencing: - Short term POCs can reach validation stage faster. - Mature cloud software needs a lot of extra tooling (LLMs don't understand the codebase, lack of places to derive good context from, and so on). - Anything in between for cloud seems to be a hit or miss, where people are mostly trading first iteration time for more refactoring later down the line. From another perspective, areas of software where things are a lot more about numbers (cpu time, memory consumption, and so on), may benefit a lot from faster development/coding as the validation phase is either shorter or can be executed in parallel. The key reality here is that I've been observing higher expectations for deliveries without a proof that we actually got better at coding in general. Which means that sacrifices are being made somewhere.

flail 1y ago
My experience correlates with this assessment. The closer we are toward prototyping, the bigger leverage we gain from quickly generated swaths of code. It's simply because we don't need to care about all the quality guardrails. After all, it's a prototype. With a more complex code base (and a less popular tech stack), the perceived gains quickly diminish. Beyond a certain level of tech debt, AI-generated code is utterly useless. It's no surprise that we see people who vibe-coded their products with no technical knowledge whatsoever, and now they call professional engineers to untangle the mess. A software agency I know well responded to the rise of AI somewhere between the lines of "Now, we'll have plenty of work to clean all that mess!" Admittedly, they always specialized in complex/rescue engineering gigs. However, the "development as a bottleneck" discussion was set here in a broader context. It's not only how efficiently we are able to deliver bits of functionality, but primarily whether we should be building these things in the first place. Equally for early-stage startups and established products alike, so much of features are built because someone said so. At the end of the day, they don't deliver any value (if we're lucky) or are plain harmful (if we're out of luck). In such cases, it would have been better if developers actually sipped coffee and read Hacker News rather than coded/developed/engineered stuff.

BinaryIgor 1y ago

Interesting article, but a slightly misleading title. Other than that the discovery process of what you should build is the hardest and the costliest part, the main conclusion from the article seems to be that if you outsource the first iterations to AI via vibe-coding, you will have much harder time changing and evolving it from there (iterating); to this, I agree

IshKebab 1y ago

This is like he's picked a clickbait position, ignored how very obviously wrong it is, and argued for it as best he can. Nice try, but it's still obviously wrong.

m0llusk 1y ago

Many here are restricting the domain to engineering which makes the real bottlenecks disappear. A good reminder of the larger context is Ralph Grabowski's Marketing to Engineering ratio. Companies that spend less on marketing that engineering tend not to endure. Companies that do endure tend to spend over double and closer to ten times as much on marketing as engineering. So the real bottlenecks in development are not centered on engineering, but the coordination of engineering and marketing in order to solve problems that matter to customers in ways that customers can be aware of and assign value to. Go ahead and code as much as you want. Unless you can communicate the utility of that code to a paying customer it has no value or relevance.

estimator7292 1y ago

Developers would gain a lot more speed than what LLMs offer if Microsoft would just fucking stop using >50% of the CPU watching your compiler for... something? Nobody wants to believe it, but just try compiling C++ on Windows and again in a Linux VM. Linux in a VM on the same host compiles at least twice as fast. It's insanity. I tried a script that rsync's the project files to my server from 2013, runs the build and rsync's the artifacts back. Running the build on a Xeon 2500 is still far faster with Linux than windows on my two year old i9. Even with the overhead of sending binaries over the internet. Absolutely disgusting.

simpleshadow 1y ago

that hn can have an article stating "development speed is not a bottleneck" is indicative of the fact that development speed is a bottleneck

angarg12 1y ago

The argument that the article uses to critique AI coding is that coding is not the bottleneck, instead the testing and validation of ideas is. This is a first-degree smart argument. It presents a seemingly non-obvious idea that makes sense in retrospect. However I happen to work at the experimentation team of a hyperscaler so I have a different perspective. First, we aren't always saturating all of the potential experiments we could be running. The reasons are different, but essentially it takes time and effort to build those experimental features. If that cost trended to 0, we could make sure to have a queue of experiments deep enough. Also in our side we need to do development work to support new features and products. We have a backlog long enough to keep us perpetually busy. If dev cost trended to 0, we could always be ready to provide our customers what they need. Speaking of new products, each one our company comes up with comes with extra effort to support in our side, and yet more effort to produce dozens of AB test to validate new functionality. This is not talking about ongoing maintenance effort. Bugfixes, upgrades etc. take a non-trivial amount of effort to keep up. And this is only inside our little experimentation team. What about security, reliability, scalability, efficiency... it makes me wonder if OP has experience running products at scale. Instead I'd like to think that dropping the cost of development by orders of magnitude changes the equation of how we create products.

tomekrusilko 1y ago

[dead]

sylware 1y ago

For tons of software out there, but not all, development time is minuscule compared to the life cycle.

j-pb 1y ago

What these LLMs enable is fixing the foundations. If you considered writing a novel database, operating system, or other foundational piece of software two years ago, you had to be mad. Now you still do, but at least you got a chance. I can highly recommend these talks to get your eyes slightly opened to how stuck we are in a local minima. https://vimeo.com/71278954 https://vimeo.com/71278954 https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world

HumblyTossed 1y ago

You have the unbelievably productive programmers - we all know their names, we use the code they wrote every day. Then you have the programmers who want to be there and will try everything they can to be there - except gain depth of knowledge. They tend to be shallow programmers. If you give them a task and spell it out, they can knock out code for it at a really good pace and wow upper management. But they will always lack the ability to take a task not spelled out and complete it. Vibe-coding is like sugar and crack mixed together for these people.

throwaway-18 1y ago
The difference between Software Engineers (or Developers) vs Programmers; with the latter designation being a stretch for some.
- hombre_fatal 1y ago
  I think we should we put this title-based distinction to rest. Whether you call yourself an engineer, developer, programmer, or even a coder is mostly a localized thing, not an evaluation of expertise. We're confusing everyone when we pretend a title reflects how good we are at the craft, especially titles we already use to refer to ourselves without judgement. At least use script kiddie or something.
  - bob1029 1y ago
    In my local world: Writing code to specification is programming. Writing the specification is engineering.
no_wizard 1y ago
It’s infecting expectations I’ve noticed as well. The thing LLM coding tools expose very plainly if someone wasn’t already aware is that management would rather ship with bugs or missing features - no matter how many - as long as the “happy path” works. The vibe coders can deliver on happy path results pretty fast but I already have seen within 2 months it starts to fall apart quick and has to be extensively refactored which ends up ultimately taking more time than if it was done with quality in mind in the first place And supposedly the free market makes companies “efficient and logical”

goalieca 1y ago

Development is always a bottleneck. Writing lines of code usually isn’t. I end up pumping out more leetcode during an interview than I do during a week or two on real products. No one has meaningfully measured lines of code as a metric of productivity since my career began in the mid-2000.

khazhoux 1y ago
On the other hand, there’s tons of people here on HN who will claim that there’s zero connection between lines of code written and developer productivity. Obviously, deleting bad/unused code is good. And obviously, some tricky bugs are fixed in one line. But you can’t build something new without some (usually, very many) lines of code. No code -> no software.
- goalieca 1y ago
  What would be the function mapping lines of code to "value" look like. Most agile teams aim to deliver "value" these days. We can't put a number of value. We most certainly can't say on average that adding a single line of code adds 0.01 units of value for a certain project.
  - khazhoux 1y ago
    > We most certainly can't say on average that adding a single line of code adds 0.01 units of value for Certainly there’s no simple F(num_lines_changed) value function. There are many other parameters. But to suggest, as many here somehow do, that lines of code touched is independent to effective development, is plain ludicrous.