Repple (she/her)

  • 0 Posts
  • 3 Comments
Joined 3 years ago
cake
Cake day: June 11th, 2023

help-circle

  • This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?

    I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.

    First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.

    The things that take up more time in software development just for engineers, leaving aside things that design and pms do.

    • Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
    • Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
    • Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
    • Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.

    There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.

    Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.


  • To be more specific (for anyone interested), the next word predictors are usually a type of model called an LSTM (at least I think that’s the most common). This model type has been used for a long time for dealing with sequential data. In 2014 there was a famous paper introducing an attention mechanism. This was a rather brilliant, though relatively minor extension to how LSTMs work. Essentially between each step of an LSTM it generates some data representing the model’s knowledge of the sequence to that point. The attention mechanism looks back at these intermediate values and determines how relevant each state is to the current point in the sequence and pulls in the most relevant bits. This vastly improved the memory of the LSTM over longer sequences.

    In 2017 there was another famous paper “attention is all you need” which said something to the effect of “the attention mechanism is doing all the work, we don’t need the rest of the LSTM we can replace it by running attention between all point combinations in the sequence.” It’s actually significantly slower to run as the model grows, but much much faster to train because it’s not intrinsically sequential. This is the transformer model that’s the basis of all our LLMs.

    Obviously some massive simplifications here but as despite being fairly anti AI, I do love the engineering behind it. So yeah, pretty literally a fancy text predictor, but it turns out when you throw all the compute you can muster at a fancy word predictor is makes the world go crazy