18 ms·

The bottleneck was never the code

• wesm 6mo ago
  See also https://wesmckinney.com/blog/mythical-agent-month/ https://wesmckinney.com/blog/mythical-agent-month/
• j16sdiz 6mo ago
  (not related to the article) The flashing red dot on the web page is very annoying. Is there some design reason for that? edit: I meant the <svg> inside `trail-map-container`
  • lysium 6mo ago
    FWIW I see the red dot only at the top of the page, flashing slowly. It does not annoy me, in fact I only discovered it because of your comment.
    • christophilus 6mo ago
      On desktop, it's fixed to the left of the story, pulsing along the entire time you're trying to read. If you are like me, it will annoy you. I had to switch to reader mode.
  • FrustratedMonky 6mo ago
    I think he's going for a metaphor about groups versus individuals. There are other gray dots around the red dot. Software is a group effort, but made of individuals. Something, Something.
  • kgwxd 6mo ago
    From what I can tell, it marks the article you're on. There are other light grey dots with other article names in it.
    • jolmg 5mo ago
      Yeah. This one shows a graph: https://www.thetypicalset.com/blog/grammar-parser-maintenance-contract?trail=blog%2Fthoughts-on-coding-agents https://www.thetypicalset.com/blog/grammar-parser-maintenanc... Solid red dots are articles you've visited.
  • augustk 6mo ago
    Turning off Javascript made the dot go away.
• lysium 6mo ago
  Can someone explain the title? I think the author illustrates that the code was the bottleneck and it has shifted to context. What am I missing?
  • jorisw 6mo ago
    I think the point they're trying to make is that context known by humans and the requirements they agree on, is 'the' bottleneck, rather than implementation
  • bsenftner 6mo ago
    I think he is saying, I hope he is saying, that software has never been writing software, it has been communications with people over what the software should be, needs to be, and the entire point all along has been to achieve better collaboration with people, and implied: to achieve their collective goal. He spends a good amount of time on how slow writing software has been in the past, and that allowed the industry to over focus on the software writing. While it has been pointed out a number of times by milestone books our industry embraced that it is the communications aspect of why and what we write that is the most important. Finally now that is being forced upon us because writing code is now automated, and all that is left is the specification and the communications with humans over what and why.
  • anilakar 6mo ago
    The author argues that writing code cannot be a bottleneck because work always fills up the allotted time. Developer teams should instead focus on doing less and writing better specifications. The error in the reasoning is that while you can increase your resourcing to tenfold and gain nothing in return, the inverse is not necessarily true.
• lynx97 6mo ago
  If thats true, I am sure some C-suite manager knows this already. Assuming management knows what they do, after all, they're getting payed for this. The time where engineer are trying to educate people above them should be over. Management gets payed for the big decisions. If they tank the company, so be it. I no longer care.
• rudyp_dev 6mo ago
  I think the argument here misses critical nuance; there is a difference between code used to implement a product and when code _is_ the product. It goes without saying that agents have little to no product sense in any discipline. If you're building a game or an app or a business, your creative input still matters heavily! And the same is true for code; if the software is your product, then absolutely the context missed by skipping the writing process will degrade your output. That doesn't mean that writing code wasn't a bottleneck even for creating well structured software projects. Being able to try multiple approaches (which would have previously been prohibitively expensive) can in many instances provide something a room of bickering humans never would have reached.
  • jorisw 6mo ago
    > difference between code used to implement a product and when code _is_ the product Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.
    • jpollock 6mo ago
      Code you ship vs tooling you use to build the code. So, the product vs everything that is needed on the way, but isn’t the core. CI/CD tooling, template population…. Things you write a use once/use few script for. I typically end up with a library of tools to deal with repetitive finicky tasks.
    • rudyp_dev 6mo ago
      I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck. If you're writing OSS code or software projects expected to be used by others that may have constraints like that, then by all means the code that gets output matters itself. But even still I'd argue that the cost of writing code manually to get there is still a bottleneck.
• nilirl 6mo ago
  Bottleneck for what? More features? I don't think amount of software is what determines whether a company does well. I don't think capturing quantity of context is that important either. Now, quality of context. How well do the humans reason? Then, attitude. How well do the humans respond to bad situations? Then, resource management. How well does the company treat people and money? Finally, luck. How much of the uncontrollables are in our favor? Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.
  • neogodless 6mo ago
    For business, software applications are tools that facilitate "the thing" that generates money. (We in the software world think that _thing_ is software and software _features_, but outside that world, there's usually a different _thing_.) The bottleneck for making software applications better at being used by (non-software) businesses is making sure the software does all the software things that actually benefit the business. Save time. Make humans more productive. Reduce human error. Make the business more efficient. Increase profit margins. All of those things are a bit difficult to predict and quantify. You start with ideas of what might help the business, you maybe design, prototype, trial. Ultimately you build or enhance software applications, and try to measure how well they're making the business better. In all of this, making sure software is addressing the right problem in the right way, and ultimately making the business better - that's a hard problem! Regardless of how fast and easy it is to make software. But yes, the speed can really help. You can prototype and trial and improve the feedback loop.
    • skydhash 6mo ago
      > But yes, the speed can really help. You can prototype and trial and improve the feedback loop. Based on what I’ve seen, prototyping has been always easy. You don’t even have to build software for the first iteration. For UI stuff you can use a wire-framing tool. What has happened is that we abandoned the faster iteration methods (design think tank, quick demo and UX research,…) and we have full in on building the first idea that came in and fostering it on the users. That process is very slow and more often goes wrong.
• jorisw 6mo ago
  > Agents that consume context need agents that produce it. Once that loop is running, the organization has a written substrate it would never have produced on its own. I'm not sure a business is helped by documentation that distilled from (hopefully present) PR descriptions and comments in JIRA, by agents. Or wherever this context is supposed to be reverse-engineered from.
  • hiohio 6mo ago
    [flagged]
• jugg1es 6mo ago
  I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have worked at in the long-term.
  • rkozik1989 6mo ago
    Any competent engineer should understand that engineering is just the assembly line side of product development. Deciding when to release which feature, bug fixes, etc. and the development/management of the product in general has always been the real challenge, and a lot of the strategy involved in doing this relies on feedback loops that AI cannot speed up. Though at the same time I do feel like leaders on the business side often scapegoat engineer's speed as an excuse instead of taking responsibility for poor decisions on their end.
    • anonyfox 6mo ago
      I get what youre trying to say but this is actually a bad picture to defend. product and engineering should go hand in hand, with one side informing the other. Engineers sctually giving a shit about a product will tell product possibilities they havent even considered, product people caring about engineering will not propose utterly stupid things. and I for one can spot when a product is well designed but poorly made, as well as when a product is perfectly crafted yet useless. the sweetspot is both. and even with the speed multiplier of AI, having a proud in the craft and being actually good in it as an engineer makes a night and day difference for the final result.
      • deleted 6mo ago
        [deleted]
  • dyauspitr 6mo ago
    It’s part of the problem but AI also can crush this on pure lines of code and functionality alone. It can put out 100,000 lines of somewhat decent code in a day. That usually takes months or years of manual coding for a team.
• nayroclade 6mo ago
  It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.
  • drfloyd51 6mo ago
    They are still anti-social. But they see the “social” as a way to feed the AI better, to make better code. The focus is still the code.
  • forgotaccount3 6mo ago
    > nakedly hypocritical How is it hypocritical? If in the old world, the very important process that used up a lot of time and benefited greatly from no distractions was the actual writing of code then interruptions for various ceremonies with limited value other than generating progress reports for some higher ups would feel like a waste of time. That same person in the 'new' world where writing code is very fast but understanding the business and technical requirements that need to be accomplished is the difficult part would then prioritize those ceremonies more and be ok with distractions while their AI agents are writing the code for them. It's not hypocritical to change your opinion when the facts of the situation have changed.
    • abduhl 6mo ago
      Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think is that it’s some kind of ego satisfaction play people make when their place in the world is threatened.
• luodaint 6mo ago
  The paper hits the nail right on the head, but it misses the mark on the next constraint: how to decide what to build. In the old days when writing code took up a lot of resources, the constraint was self-correcting since being off in your implementation was obvious enough that the error could be easily seen after three months of work on the wrong feature. Today, you could spend five wrong efforts in the same amount of time that it used to take you to implement one wrong effort.
  • mihailupu 6mo ago
    [flagged]
• jaccola 6mo ago
  The company website linked in the article is broken https://www.dottxt.ai/ https://www.dottxt.ai/ on (mobile and desktop) Safari. Looks like your cert doesn’t cover the www subdomain.
• ZeWaka 6mo ago
  > Producing easily consumable context is precisely the thing humans don’t like to do. I don't think this sentence speaks for me. This is the sort of thing I love to do.
• spiderfarmer 6mo ago
  For me it was. Solo entrepreneurs are the ones who profit the most from AI assisted development.
  • frollogaston 6mo ago
    Or startups where coding was always a bottleneck because it was very expensive to hire swes, unlike big corps which would often throw swes at a problem.
• Antibabelic 6mo ago
  What kind of projects are people working on, where understanding what features the management wants is the only difficult part and the rest can just be "typed out" (or, today, offloaded to an LLM)? If that's what you do, then I'm not surprised so many people on HN think LLMs can replace them.
  • odie5533 6mo ago
    I've found the more senior you get, the code seems more fungible, and the process seems more important and difficult.
    • jayd16 6mo ago
      Isn't that just ascribing difficulty to the parts of the process you're closer to?
  • hnthrow0287345 6mo ago
    This is like 80% of CRUD apps. Sometimes they have a few interesting problems but not like the upper 20%. Most of them are hot garbage in terms of code quality because of the offshoring and layoff cycles.
    • IanCal 6mo ago
      Also even the more complex things will have a lot of simpler code in them.
  • vehemenz 6mo ago
    Uno reverse. What kind of limited project experience would lead anyone to think that there isn't an enormous continuum between code difficulty and organizational problems in the space of software development?
  • deepsquirrelnet 6mo ago
    Any discussion related to this topic always seems to assume everyone uses code the same way and for the same function, and then forces the rest of the world through that lens. So here we walk around the circle one more time again, voicing our anxieties, talking past each other, waiting for the next opportunity for commentary to come in half an hour.
• BrokenBuild 6mo ago
  I can see the division here already, and the cogs are afraid. As a dev of 25+ years, currently working for a small company who came from a global company, I see both sides. I'm very excited about AI and love to see my projects come to life so much faster. I still love the craft of code, but its always been about the product for me.
• zabzonk 6mo ago
  > Real programmers don’t document their programs. Probably true, but I, for one, have always liked documenting how the code I've written should be used, whether programmers calling APIs I've created, or end-users actually making use of a program's executable. I find writing the docs just as interesting and creative as writing code.
  • MyHonestOpinon 6mo ago
    > Real programmers don’t document their programs. This is kind of a straw man. I suspect people say that tongue in cheek. Good programmers try to make their code clear and easy to understand. They add comments to clarify, specially their whys. The problem I have with documentation is that you end up with mountains of documents over time about a lot of things that are no longer true and many times contradictory. The only solution I have seen is making sure that documents have owners that update them periodically.
• dividendflow 6mo ago
  [flagged]
• bucktrack 6mo ago
  [flagged]
• tlkan 6mo ago
  One of the bottlenecks has always been the code. That code has been stolen and is being laundered while companies rely on mediocre engineers who have never written anything of value to promote the burglary tools and call the process "writing software". It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper". I agree with the point of the article though: code generation does not really work, the results are bloated and often wrong and people already had more features that they could absorb in 2020. The solution to this mess is to have 18 year olds boycott studying computer science altogether, since the industry (and mediocre fellow "engineers") will treat them like human garbage.
  • mayhemducks 6mo ago
    My status after reading your comment: https://imgflip.com/i/7yki7x https://imgflip.com/i/7yki7x Agentic tools are "burglary tools" -> Younger folks should not study CS?
  • i_love_retros 6mo ago
    I think the solution is to fix society so that we value quality over quantity, self betterment over getting rich, and making society better for every one rather than worshipping billionaires.
  • mountain_peak 6mo ago
    Personal anecdote. When I started as a wide-eyed university co-op, I was surrounded by a team of aging mainframe developers who had been coding since the 1960s. Their backgrounds ranged from working their way up from the mailroom to astrophysics to masters degrees in computer science. What struck me was how the entire team treated coding as a form of art. Of course, it had to be functionally correct and maintainable, but you could glance at a snippet of hyper-efficient PL/1 and instantly tell that 'Larry' or 'Trudy' wrote that routine - each programmer had a unique style, along with just the right amount of comments to make you laugh and guide you through difficult bits. Most of the team has since passed away, and their code has been long replaced by modern systems, but what stuck with me is that great code is a form of art - where your individual style, insights and personality can be reflected in code for the better. The systems were efficient, responsive, extensible, and a joy to work on, since the team took a great deal of pride in their work. It really is akin to being affected by a clever and insightful work of art. A decade later, and programming became something to "make money" at, which flooded the market with many people who never really had a deep love of programming, and I guess that's ok, but something has definitely been lost along the way. To your point, it may not be such a bad thing if people started boycotting computer science and it again became more of a calling than purely an avenue to employment.
• frollogaston 6mo ago
  Doesn't add up. I used to spend more than half my time coding, as did others. Besides the obvious cost, that coding took wall-time which meant talks had to wait. Sure a poor collaborator will jam things up a ton, but a team of at least ok collaborators used to be bottlenecked on code.
• freejazz 6mo ago
  It seems like so many developers know this, yet here we are. SV pushing this AI slop economy. More code! Faster! Less testing! Less understanding! It's what we NEED!
• stego-tech 6mo ago
  The bottleneck has always been the human element. I too used to be one of those up-my-own-ass engineers who thought the most important part of my work was the machine, and it wasn’t until I began actually listening to others and their problems that I realized my function was far more than mere technology scaffolding. That said, I’m also increasingly aware that puts me in a minority group. I got to see this first hand in a recent org where their codebase and product design hadn’t meaningfully evolved in nearly thirty years. NAT was a “game changer” to them - and one they refused to implement without tons of extraneous testing they would deliberately undermine, stall, and sabotage so they didn’t have to modernize their code accordingly. It was easier for the developers and stakeholders to preserve their own status quo rather than entertain alternatives, to the point of open hostility (name calling, insults, screaming, and a few threats) to anyone suggesting otherwise. The human element has always been, and always will be the bottleneck. Stakeholders who don’t contribute updated or accurate datasets to automation systems, or who hold back development to preserve personal status and power, or who otherwise gum up the works on purpose to game their own careers. That’s not to make the argument of “replace all humans with machines”, mind you. Just stating that an organization that incentivizes bad behavior will be slowed down versus ones that incentivize collaborative outcomes, and AI is just going to turbocharge that by removing the friction associated with code creation and shifting that elsewhere.
  • SoftTalker 6mo ago
    > name calling, insults, screaming Never experienced this at a job in 30+ years, and that includes my first jobs in fast food. If you experience this at work, find another job. This isn't normal. It's extremely dysfunctional in fact.
    • stego-tech 6mo ago
      I was already looking, but they ultimately made the decision for me in January with a RIF. Thing is, this job market is hell. There are folks who have to choose between the abuse or making rent, which is why we need stronger incentives for organizations to discipline said abuse rather than let it permeate because existing penalties lack teeth.
• kylestlb 6mo ago
  Absolutely matching the gut feel I've had lately. We've always been pretty good at producing bad code very fast. All of the other stuff - dependency management, learning what's valuable, ownership & boundaries, context switching costs, etc... have always been the bottlenecks and it's just more obvious now.
• blueTiger33 6mo ago
  the bottleneck was never the software, that is the ship we ride, people, are part of a team focused on a goal, they work together because they believe in that the ship is worth riding on and will reach its destination, the ship should carry food people want, team decides what food will be consumed, captain tries first the food, if food is good and people want it, people buy more
• pu_pe 6mo ago
  Sometimes code is definitely the bottleneck. For example some organizations have a very bureaucratic process guarding which projects get access to a development team and when. That's not needed if implementation is now faster/cheaper. I'm also skeptical that development velocity is so separate from all those other things (context, stakeholder alignment,etc). It's much easier to get actionable feedback when you have a prototype.
• paldepind2 6mo ago
  From the article: > Jevons Paradox: when something gets cheaper, you tend to use more of it, not less. That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper. What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), but still the total usage of that resource increases.
  • TheLudd 6mo ago
    Should the paradox not be that we PAY more for it? Or, if some process is made more effective, i.e. takes shorter time, we spend more time in that process.
    • IshKebab 6mo ago
      No, we pay less for it. But there's much higher demand so overall use goes up.
      • TheLudd 6mo ago
        Right. That is not a paradox as stated. The paradox would be: * a TV used to be really expensive. So a home just had one * over time TVs become half the price. * now a home has 3 TVs, i.e paying 150% of what they initially payed.
        • IshKebab 6mo ago
          It is a paradox. The paradox is that increasing the efficiency of resource usage can lead to more resource usage. If you think that isn't a paradox because you can fairly easily explain why that is the case, you need to go and check what "paradox" means.
          • TheLudd 5mo ago
            You said: > No, we pay less for it. But there's much higher demand so overall use goes up. This is economics 101, not a paradox. To clarify how I read you: "If the price goes down, more people will want to buy, hence more units are sold" The paradox is that _one_ person, or entity, pays more as the price goes down.
• HarHarVeryFunny 6mo ago
  > What may save us it that agents are unreasonably good at reading exhaustively. An agent will read every PR comment, every closed issue, every commit message, every stale design doc ... > Not just “this module exists,” but “this module is weird because the migration had to preserve old behavior,” or “this benchmark matters because a previous optimization silently changed the distribution.” The thesis here is that an LLM will document code better than a human (although based on human artifacts), since churning through huge quantities of text is what they are good at. A few thoughts: 1) Yes, an LLM may be able to pull comments out of commits and PR comments and put them back in the code where they belong, but I question how often a developer too lazy to put a vital comment in the code would put it in a commit message instead! 2) "The truth is in the code" has always been true, and will always remain true. If the comments differ from the code, the code defines the truth. Pulling comments from stale external documentation and putting them in the code does more harm than good. 3) Comments that can be auto-generated from the code don't add much value (lda #1; add one to the accumulator). 4) Comments about the purpose or motivation of the code, distinct from 3), such as the "we had to preserve backwards compatibility" example, or "this code does this non-obvious tricky thing because ...", are where the value is, but the LLM is highly unlikely to be able to discern any unwritten motivation by itself. If the human developer left a comment somewhere then great (assuming it is still relevant) Most of the discussion we see about LLM coding is how fast it can churn out thousands of LOC on a greenfield project, or how good they can be at finding bugs, but neither of these are very relevant to the main job of developers which is maintaining and extending existing codebases. It would be lovely if most projects were greenfield, but they are not. In any large project that has been maintained over a few years or more, there will inevitably be an ever growing accumulation of bug fixes and patches for specific issues that have been discovered in production, likely poorly documented and out of sync with any original documentation that may have existed (which anyway tends to be more idealistic and architectural in nature, not capturing these types of post-deployment detail and special cases). The natural tendency of an LLM is to want to rewrite code to match the statistics of what it was trained on, and they need to be reigned in via prompting to resist this and not touch more code than is minimally needed for what is being asked. Of course asking an LLM to do something is a bit like asking a dog to do something - sometimes it will, and sometimes it won't. I expect over the next few years we'll be experiencing, and reading about, more and more cases where LLMs have introduced bugs and regressions into mature code bases because of this - rewriting code that should have been left alone. The general rule is that if you are tempted to rewrite something you better first understand why it was there, coded the way it is, in the first place. I can't help but compare the current state of "AI" (LLMs) to the early days of things like computer speech recognition or language translation when they were considered amazing, and everyone was gushing about them, but at the end of the day the accuracy still wasn't good enough to make them very useful - that would take another 10-20 years. Another historical lesson/perspective would be expert systems which at the time were considered as AI and the future of machine intelligence (the Japanese "5th generation systems" were going to take over the world, CYC promised to offer human level intelligence), but in retrospect were far less important. It won't be until we move on from LLMs to something more brain-like, deserving to be called AGI, that LLMs will be put in their historical perspective. At the moment DeepMind seems to be the only one of the big labs admitting/recognizing that scaling LLMs isn't going to achieve AGI and that "a few more transformer-level breakthroughs" are needed. Hassabis has however talked about LLMs (GPTs) still being a part of what they are envisaging, which one could either regard as a pragmatic stepping stone to real AGI, or perhaps that they are not being ambitious enough - building something that still needs to be spoon-fed language rather than being capable of learning it from scratch.
• auggierose 6mo ago
  I cringe every time I read the word "load-bearing" in an article.
  • jwoq9118 6mo ago
    It instantly made me think this was either written by AI or heavily edited, and I hadn't gotten that sense until the moment I saw load-bearing. I hate that em dashes have been killed by AI as well. Hundreds of years ago Charles Dickens was using them in his novels and today someone will read his books and in ignorance actually think AI wrote it.
    • auggierose 6mo ago
      I don’t mind em dashes, I use them myself. But load-bearing context, that’s just really bad writing.
• tuo-lei 6mo ago
  [flagged]
• sharts 6mo ago
  Velocity, velocity, velocity! Ah yes, velocity always seems to matter except to those that don’t need to worry about it.
• kadhirvelm 6mo ago
  Totally agree, we wrote our own piece similar to this: https://productnow.ai/blogs/teams-that-coordinate https://productnow.ai/blogs/teams-that-coordinate I really think as code becomes cheap, misalignment between people, teams, and organizations is going to hurt a lot more, especially when everyone is trying to move at break neck speeds. I also think a big piece of this is human attention and inertia. Aka, why bother doing the hard work to coordinate with others when you can just ship whatever you’re thinking. I think whichever organizations can figure out the human and cultural aspects to this will do phenomenally
  • doitLP 6mo ago
    “Something went wrong with the editor” when loading page
    • lucasacosta_ 6mo ago
      same
    • kadhirvelm 5mo ago
      Whoop sorry, should be back now
• ChrisMarshallNY 6mo ago
  > Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do. Love that. I agree, in particular, about the context. That’s where long-retention, experienced, teams pay off. I managed one of those for decades. When they finally rolled up our department, the engineer with the least seniority, had ten years. When a team is together for that long, the communication overhead drops to an almost negligible level. That’s what I find most upsetting about the current culture of mayfly-lifespan employment tenures. Nowadays, I work mostly alone. I’m highly productive, but my scope is really limited. I miss being on a good team.
  • bombcar 5mo ago
    That’s the secret behind the “mystery” of startups - once you stop looking at what they’re doing you realize it’s all about the team - a good team will become a serial startup group doing all sorts of different things - but since they’re a well-oiled team they execute at an impossibly high level.
• syntax-sailor 6mo ago
  An awful lot of problems can in fact be solved by 'more code' in fact. People seem to straw man this in terms of product feature surface. A lot of places skip creation and maintenance of decent observability - that's code. We can now easily use advanced, code heavy testing techniques like property testing - code. We can create environmental simulations to speed up and improve integration testing - code. We can lift up internal abstraction levels, replace boiler plate with frameworks, DSLs - code.
  • apsurd 6mo ago
    All listed are in service of the product feature surface.
  • sieabahlpark 6mo ago
    [dead]
• deleted 6mo ago
  [deleted]
• randallsquared 6mo ago
  So managers are overwhelmed because the code is now happening a lot faster? It sounds like the immediate bottleneck really was the code, at least frequently. Now it seems the bottleneck is managerial.
• theptip 6mo ago
  > They are waiting on the next well-formed spec Is this actually true? Maybe in a widget factory. I think it’s an anti-pattern for the new world. When you look at places that are shipping at insane pace (like Anthropic) the secret is not accelerating the writing down of a roadmap and we’ll groomed backlog, it’s empowering smart individuals to run their own end-to-end product improvement loops. You can slightly reframe the OP by saying “the bottleneck is product ideas”, but “well formed backlog items” IMO frames it as more structured and hierarchical than it should be.
  • apsurd 6mo ago
    The problem with this is that everybody thinks they have better ideas than they do. And engineers are probably the worst offenders in that they're smart enough to make a case that deludes themselves. The insane billion dollar companies ship straight to production because they have PMF so anything and everything gets signal. The same happened with Facebook and Google. And it was always cautionary advice to mimic these giants. It's a bad idea for all the rest of us.
    • theptip 5mo ago
      Well, if you actually build the feedback loop then you solve this by weeding out the bad ideas. This is like going to a startup as a senior bigtech engineer - if you can’t ship it becomes clear quite quickly. Regarding the talent dysmorphia issue - the best way I know of getting people to step up is to give them more agency and more accountability. The new world will require that IMO. I think Google etc are more a story of how much you can get away with when you have a strong monopoly. Their orgs are not shipping fast, nor good at shipping products. (Google in particular is incredible at infra but laughably bad at consumer products.)
• jmilloy 6mo ago
  Code is a liability. I think it can be easy to look at code as an asset, but fundamentally it is a liability. Some of the "bottlenecks" to new code are in place to make sure that the yield outweighs the increased liability. Agents that produce more code faster are producing more liability faster. Much of the excitement and much of the skepticism about coding agents is about whether the immediate increased productivity (new features) and even immediate yield (new products or new revenue) outweighs the increased long term liabilities. I'd say we won't find out for another 1-3 years, and of course that the answer will differ in different domains. From this perspective, attempting to build these bottlenecks into the agentic workflow directly makes some sense. Supplying coding agents with additional context that values a coherent project vision and that pushes back against new features or unconstrained processes would be valuable. Is this what the article is trying to get at? Is this attempting to make some agents essentially take on product management responsibilities, synthesizing as much as possible into a cohesive product vision and reminding the coding agents of that vision as strictly as possible? Should these agents review new proposals and new pull requests for "adherence to the full picture", whether you want to call this "context" or "vision" or something else? I think these agents might do an exceptionally good job at synthesizing context and presenting a cohesive roadmap that appears, linguistically, to adhere to the team values and vision. But I'm doubtful that they can have the discernment that a quality manager or team can have. Rapidly and convincingly greenlighting a particular roadmap could do more harm than good.
  • solatic 6mo ago
    > Code is a liability You're over-simplifying. Code in and of itself is neither an asset nor a liability. The minimal amount of code needed to solve business needs with no additional complexity is an asset with some maintenance liabilities attached (same as how a farmer's tractor is an asset that needs to be maintained), with depreciation if unmaintained (bitrot). Any code used to build unnecessary complexity is pure liability.
    • quikoa 6mo ago
      Yes, if code is only a liability then just delete the code and poof liability is gone.
• SadErn 6mo ago
  [dead]
• Brysonbw 6mo ago
  Everything in life revolves around people, and even more so today
• web-cowboy 6mo ago
  I'm finding counterexamples of this constantly now that I can have an agent rewrite large sections of my codebase that have been sorely needing it. - Moving to a newer and more modern test library - Refactoring my data layer so it's easier to read, based on years of organic changes that need to be baked in and simplified - Porting some functionality to another language to vastly improve performance I agree with the overall sentiment, but having an agent at my finger tips who can really crank out large-scale, involved code changes is unclogging quite a few backburnered todos lately for me.
• woodydesign 6mo ago
  [dead]
• nibab 6mo ago
  the tediousness of keeping documentation up to date and the natural tendency towards small attention spans has always come up as a tax on organizational efficiency: complicated org structures, legibility exercises, communication tollgates etc. there is real value in reducing the friction in the former so that the latter becomes less of a burden. at the same time, context poisoning is a real cognitive problem for humans too and I can't tell you the number of times I've seen irrelevant details become a drag on execution. my fear is that having too much context will only cause bikeshedding and a revisiting of prior decisions. frankly, our organizational structures were already pretty good at creating mechanisms for eliciting the right implicit context at large scales. it is possible that we're just going to come up with the same mechanisms from first principles...
• charlieflowers 6mo ago
  I have been thinking about this a lot lately. How do you capture key factors succinctly, and even harder, keep it succinct as it evolves? The shrinking that property based testing does when it finds an issue is kind of what we need for specs/context.
• tylershamy 6mo ago
  [flagged]
• gavinh 6mo ago
  If I read “load-bearing” or “blast radius” one more time…
  • DrJokepu 5mo ago
    Don’t forget about the “smoking gun”
• TedDallas 6mo ago
  Ask yourself what monks did when scribes were replaced by the printing press. If I was a scribe at the time I’d be thrilled because of all that extra time available to work on beer productivity metrics.
• neosat 6mo ago
  "What slows down a team where agents do the implementation is the production of specifications precise enough for an agent to pick up and run. Roadmap, written down. Acceptance criteria, written down. The “what we actually want” forced into precision, be it via a test suite, a ticket, or a written design." This is merely speed of development and not the velocity of a company towards higher value. There are many PMs confidently (using the same AI tools), without a clear deep understanding of the user problems or why the requirements will be adopted by their target users (or even who the target users really are), writing these done elaborately. So yes this will lead to faster end-end execution. But if the product is used or if it sits unused will depend on things beyond the above.
• stevefan1999 6mo ago
  Before going to work, we're fed algorithms and data structures and how they are the bottlenecks that makes wasteful use and here's how to utilize them; only to naively know from hard stories that the actual bottleneck is always from the people, the H-factor, except this time H stands for human. Insane amount of bureaucracy, paperworks, and how we are missing deadlines so we write shit code that the quick and dirty solutions were never replaced. Algorithms and data structures therefore are more like helping you utilize the machine economy better, but it doesn't have any meaningful impact on the social aspect of it. That's a hard lesson I had to learn from my two previous job, though now I'm considering starting my own small business just to make a little bit of living enough to survive. But now my ADHD kicked in and is still lazy and I had so many concerns whether the market validation is great, how to deal with situations if I broke customers stuff, how to gain (and hopefully not regain) trust if any bad things ever happen, what if I want to go vacation and suddenly the server broke and got code zero (the highest level of alert I termed internally, when you had alertmanager flashing everything red, network storage is down, corruption happened) during a trip to Bahamas. I'm still in the watershed of thinking really to do this or not, but the job market is filled with ghost jobs that are not worth my time either, I'm basically "dead locked" right now and had to make a decision quick. Either choice is fucked for me, as I started to notice after going to work, despite I got some really interesting ideas in tech, but I'm not a charismatic person so I can't really make those idea to fruition, because no one wants to listen to me and implement it together, so I'm pretty sure it is impossible for me to be a great leader (tech lead probably, but CEO level of leadership and coordinator and manipulate the grand scheme of thing, nah, I pretty much can't do). Now the problem is, even if I'm pretty sure to get fucked, you should choose the one that inflicts minimum pain to you. So far having my own business seems like a less painful to die and bankrupt, and I'm preparing to sell off some of my stuff to get a last dip of my fortunes and have fun. Will see how it looks. Bankruptcy is nothingburger in this modern society perhaps. Now you see how the bottlenecks can't even be the code anymore and even goes beyond code, despite having the same core template: I don't even have to code, to repeat the same "quick and dirty" kind of mindset in another domain, in another instance. That's something LLM, heck not even AGI can solve: decision-making based on situations with limited time and resources, and it can be personal or organizational or even structural. This is very much not going to be solvable by a bunch of lines and statements and expressions, but it really need some time to dig in and compromise. Pick your kool-aid and drink it
• trjordan 6mo ago
  Yes, but: writing code always teaches you something. I've worked at founder-sized startups and $xxb dollar public companies. I've never read a product spec, a pitch deck, or a PRD that describes a solution that, if implemented in the way described, would solve the problem. Building the thing teaches you how it should behave. Software is a complex, interactive medium. Iterating in the code, with people who understand the problem and care to see it solved, is the only way I've seen valuable products get created. Meetings and diagrams help, but it's not until you write some working software that you know whether you have something.
  • andrewingram 5mo ago
    As they say (they being me), no design survives implementation.
• skiing_crawling 6mo ago
  As software engineer, we should collectively realize that this is all cope. Every article or comment about how AI will never be smart enough, etc, etc will only be true until its not. One of our main valuable skill sets is now partially automated. Some of us are completely obsolete and its coming for the specialists and more experienced ones within a decade tops. You're not going to convince anyone that "um actually we're better because we bike shed more". Stuff like this is ridiculous and comes off as frantically trying to save your ass. Its pretty obvious at this point that we will just throw more matmuls at it until it can do this or something equivalent. > Agents cannot do osmosis. They do not get context by being in the room, by half-hearing the planning conversation, or by carrying the memory of the last incident.
  • Pannoniae 5mo ago
    Yeah, you're definitely right about the shifting goalposts ("it's a stochastic parrot" -> "it hallucinates all the time, it can't even get APIs right" -> "it can generate functions but can't reason about the codebase" -> "the bottleneck was never shipping code") At the same time, humans can move up the abstraction ladder faster than the LLMs can. At least, some humans. Agents can produce lots of code. They can also do the entirely wrong thing. The impact of wrong decisions have been massively write-amplified with more and more intelligent LLMs. With earlier ones, it got a sentence or a function wrong, you reprompted, the cost of a mistake was 10 seconds. Now, you can burn hours or even days of work on the entirely wrong thing without a competent human operator stepping in and course-correcting. The trajectory of agents have been bigger and bigger context windows, bigger autonomy, but at the same time, a bigger blast radius. In this context, I don't think the human experts will be out of their jobs any time soon.
    • skiing_crawling 5mo ago
      > At the same time, humans can move up the abstraction ladder faster than the LLMs can This was kind of the point, its only true for now. I agree with you that this kind of stuff will take longer. I don't think there's probably good training data for it right now. Handling abstractions and course correcting is probably the job now, and it also happens to be exactly the data that we will be typing in our prompts. They'll train on it or something like it.
• keithnz 6mo ago
  I think this is the wrong conclusion. Whether code is the bottleneck likely depends on the organization. In mine, code is the bottleneck. AI has pushed it so validation is now the bottleneck. If it is such that the devs are "middlemen" such they can't spec things, then I think whoever can spec things is likely the bottleneck.
• keeda 6mo ago
  The bottleneck was ALWAYS the code, which is why everything was built around it. This is the key line right here: > Negotiating, agreeing, communicating the shared picture of what we are building has become the work. And it’s just as hard as it was. But if software (via code) is what we ultimately produce and sell, how did we get here? The main reason is the following lemma: Lemma A: "The loss of fidelity of what can fit in any one person's head scales superlinearly (exponentially?) as the scope of work scales up." Or more colloquially: "It is impossible to fit a large scope of work in any one person's head." This is largely because any non-trivial task is a fractal of smaller dependencies. The chain of logic to today's situation is then obvious: 1. Writing code requires humans who are slow and expensive. 2. To do large things we need large groups of humans. 3. As the number of humans grows (like beyond 5? 10?) it becomes impossible to keep them aligned, largely because Lemma A. 4. We need to coordinate these humans, so: enter managers! 5. But even a manager can't manage too many people and coordinate with all other managers because, again, Lemma A. Enter hierarchy! 6. As the size of the organization grows, so does the coordination overhead (exponentially, if Google AI overview is to be believed) until as,that quote surmises, the majority of the work is just that. 7. Coordination costs (or "Conway Overhead" as I call them) are very well understood in the literature, but this also brings in undesirable dynamics like bureaucracy, politics, organizational metrics (also due to Lemma A, but now triggering GoodHart's law!) and eventually territorial disputes and empire-building. Lots of friction and subtle mis-alignments. As you can see the overhead scales superlinearly with the number of leaf workers added. And for the same reason, once the leaf workers are decimated because one worker can now do the work of a whole team, the entire organizational overhead above that is gone, which is also a superlinear change! Assume a conservative 2:1 reduction in ICs and a 1:5 manager:reportee ratio, a simplistic hierarchy that was: 1 CEO -> 5 VPs -> 25 Dirs -> 125 Managers -> 625 ICs now becomes something like: 1 CEO -> 12 SVPs -> 60 Sr. Managers -> 310 Sr. ICs. Not only did that eliminate 300 ICs (mostly junior I suspect) it took out 60 managers and removed an entire layer of Directors from the hierarchy! Worse, the leaf-layer will probably get decimated 5:1 not 2:1, and this will also eliminate coordination-specific roles like Program Managers. The rest of the hierarchy is much fewer but mostly more experienced (or politically savvy) people. They will be paid more, but not superlinearly more, of course, what do you think this is, socialism? It's very much a pyramid scheme of cards built on that one bottleneck. And this bottleneck applies for pretty much all knowledge work. Once that bottleneck opens up, everything collapses. This is why I fear that the coming job changes are going to be much more disruptive that people realize, something I'm extra concerned about as a parent of high-schoolers.
• oxag3n 6mo ago
  It shares some ideas with Peter Naur "Programming as Theory Building". Quote from the post article: "To quote Michael Polanyi: we know more than we can tell. Some load-bearing context exists precisely because it was never put into words, and writing it down would change what it is." Imagine how much knowledge exists only in the heads of software engineers, with code being just a functioning footprint of that "Theory". I know SRE in FAANG who told me that multi-billion system is supported by tribal knowledge within their group, and for years, even pre-AI it was a protection against automation.
• coldtea 5mo ago
  >The goal was to test our structured-generation algorithms and their open-source counterparts, replacing the naive “does it accept this string?” with something closer to the real problem: “does it produce the right token distribution?” The experiment kept coming up in conversation, then returning to the roadmap. Last month, I spent half an hour explaining the method to Codex. A few hours later, it had produced a working first version. That’s all it took. Proving that the bottleneck, was, in fact, the code. It's just that the AI wrote it now. The person who thought "the bottleneck wasn't the code" already had the goal discussed and coherent in their mind. Code as bottleneck doesn't have to mean "I wanted this feature but it took me many months to finally code it". It is also "I wanted this feature for 2 years, but the friction in sitting down to put it in code and spending 5-10 days on it, etc, put me off". If the code wasn't the bottleneck, they could just sit and write it themlseves. But, they didn't want to go through the effort and time spent of coding it themselves, as they knew it wouldn't take as little as with the LLM. (And even when you don't have a clear final spec in mind, the exploratory code+check+discard+retry-new-design, is also faster with an LLM, precisely because the "code" part is). In other words, the code was the bottleneck. The post appears AI-generated itself, just with instructions to avoid obvious constructions, which still makes for tedious reading.
  • remilouf 5mo ago
    Author here. Sorry my writing is tedious. Next time I’ll use AI to make it more readable.
• booleandilemma 5mo ago
  I swear AI has made this entire industry crazy. Here's Robert Martin saying non-determinism in AI is ok: https://x.com/i/status/2044440457422549407 https://x.com/i/status/2044440457422549407 Who wants a non-deterministic banking app?
• austin-cheney 5mo ago
  It typically is the code that’s the bottleneck, but not writing the code. My career is littered with numerous delays from slow applications. I am stuck with an editor based on Eclipse. It’s slow and periodicity pauses or crashes. I am stuck with build jobs that take 15-20 minutes. I am often stuck with web apps that take forever to do a task that should take 50ms max. The list can go on and on. Every delay is a distraction that shatters my concentration. I still write code at work but I am in management now with dozens of other people and administrative distractions. When the software is slow it become my lowest priority. I don’t care who that impacts because if it really mattered we wouldn’t be held hostage by all this slow syrup of software pulling each of us under.
  • estetlinus 5mo ago
    Which editor and why eclipse?
    • austin-cheney 5mo ago
      Because our software platform requires use of a proprietary editor built over eclipse. I use other editors when I can deviate from the official one.
• socalgal2 5mo ago
  The bottleneck for my personal projects was the code. So many have become unblocked because of LLMs
• munk-a 5mo ago
  I can type faster than I can think of the correct things to type. My experience may be non-standard but I think for most serious software folks the code has never been the bottleneck.
• mudkipdev 5mo ago
  The .txt website fails to load if you won't enable WebGL on your browser. Incredible
• andai 5mo ago
  My buddy made a music software, with synths, effects, visualizers, etc. with Claude and Codex. For him, the bottleneck very much was the code. He still doesn't know any programming. I want to say that his ability here has been accelerated by orders of magnitude, but without AI he couldn't have done it at all, so it's actually a divide by zero situation. (Yeah, he could have just learned programming... and audio engineering... and the specifics of JavaScript ... and the web audio API, and the DOM, and WebGL, and his demo would be ready in like, 2030.)
• andai 5mo ago
  > Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do. The issue is that sometimes you don't know what the system should do until you build it. A design is a hypothesis. Most of them are wrong, in subtle or not so subtle ways. (Also, as a separate issue, having a group in the first place increasingly adds negative value. If it was ever a good idea to design by committee... it's increasingly expensive to do so, in opportunity cost.)
• ern 5mo ago
  For something that was supposedly always unimportant, huge amounts of energy were spent recruiting developers based on how they produced and interacted with code. FizzBuzz was a litmus test that showed how hopeless the average developer was. Coding interviews were the real test of programming ability. Now we're being told none of that ever mattered for real? We should just admit that the game has changed (possibly, I'm not 100% convinced). Code WAS the bottleneck and coding ability was the bottleneck, but it may not be going forward.
• taneq 5mo ago
  I’ve been saying for decades that the “hard problem” of programming isn’t curly brackets or any of that shit, it’s figuring out what you actually want, in enough detail that you can explain it to a computer. The amount of detail required is less these days and the computer is better at interpreting handwavey explanations but the principle still applies.
• readgrounded 5mo ago
  Oh my god, I literally say this every day now. People think that just because its fast to generate a demo app using claude code that every production system can be built in a week. Generating code was never the bottleneck. It was deciding what to build. When you build an app using claude code, you are equal parts coder, designer, product owner, client, CEO of the universe. You make decisions lighting speed, iterate, and destroy anything you don't like at will. You can make strategic and tactical decisions at any frequency and point that you want to, without needing a bi-weekly board meeting to do it. The bottleneck is always decision making and human review when multiple humans are involved. This is especially true when we are all trying to build agentic / llm based systems where the outcomes are highly varied and its impossible to write easy tests to automatically check quality or benchmark progress.
• tonetheman 5mo ago
  [dead]
• jacktu 5mo ago
  [dead]
• whatever1 5mo ago
  Yes it was. We were stuck on never-ending design and requirements discussions because writing the wrong code was too expensive. Now if your design / requirements are wrong who cares? Tomorrow you will have a brand new stack.
• jnakano89 5mo ago
  [flagged]
• k1w1 5mo ago
  It makes me wonder if remote-first companies will have an advantage in an AI-first world because they must be more intentional about communication. By their very nature remote teams use more written communication and more intentional, and documented, processes. Perhaps the RTO mandates will turn out to be the biggest organizational mistake?
• socratic_weeb 5mo ago
  One of the most full of bullshit phrases that nevertheless gets parroted all the time, specially by clueless AI bros. If that's the case, then why programmers invested so many years creating high-level langs, debuggers, syntax higlighting, intellisense, libraries, and a myriad of other tools in order to make programming easier? You guessed it: it's because programming is actually super hard and thus a real bottleneck, and will always be.
• longevitygreenl 5mo ago
  36 years in, solo founder now, and this matches what I'm living. The code stopped being the bottleneck a while ago — Codex and Claude ship features faster than I can decide which features are worth shipping. The Jevons Paradox point lands hard: I have to actively resist building things just because I now can in an afternoon. Solo doesn't escape the coherence problem either, it just turns it into a fight with my past self about what this product actually is.
  • i_think_so 5mo ago
    Just wanted to say hello and encourage you to share your perspective. I saw that you got flagged on your second ever comment (possibly because it sounded like your first). Unfortunately, there are some very itchy trigger fingers here when it comes to shooting down AI slop. Surviving long enough to get a few karma points and not be treated like a bot was much harder than I expected, so I want to toss you an upvote and thanks in advance for sticking with it. I wish I could give you good, brief advice on how to avoid getting downvoted to death before you even get started. There are undoubtedly others who would do a better job. So I'll just say "try really hard not to appear like ChatGPT write your post." Everything imaginable is being impacted by AI, in expected and in surprising ways. Communities are going to need to put extra effort into things that used to just happen, like welcoming new members. Here's mine. (I hope I'm not wrong and that you're not actually a spammer. But I think my bet is safe enough. :-)
• virgilp 5mo ago
  One thing that is worth pondering is what parts of the "old wisdom" (if any) are no longer true. Because the set of "common sense knowledge" has a tendency to mutate in time. Take the first statement: > Impactful software tends to be written by many humans that need to collaborate. This was definitely true. Is it still true to the same extent/ in the same way? Not obvious...
• theuniverseson 5mo ago
  [flagged]
• naturalintell 5mo ago
  [flagged]