9 ms·

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our

• vrganj 5mo ago
  That guy is now running twenty agents in parallel and really scaling up his wonderful impact.
  • caminante 5mo ago
    Maybe "Hurricane Hacker" who produces "tactical tornadoes" via agents?
• chapinb 5mo ago
  Sounds a like a tactical tornado, made me think of this paragraph: “Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” - John Ousterhout, A Philosophy of Software Design
  • abirch 5mo ago
    AI can be the ultimate tactical tornado.
    • joe_mamba 5mo ago
      But it really doesn't have to be like this. For their bug bounty program, the company can just charge 5-10$ per submission to guarantee everything you send gets thoroughly reviewed by a human, and so it completely eliminates bot slop DDoS submissions overnight. If your bug and PR was actually good, then you get 10 + 1000$ back, and if it wasn't good, then you need to do better due diligence next time, and the skilled human feedback you received on why it wasn't good, was a valuable lesson for your engineering career, and it only cost you the price of a Starbucks latte, and it also cut out all the scammers polluting the system. This way everyone wins. I said it before and I'll say it again, for opportunities open to the entire world on the internet, adding monetary friction is THE ONLY (anonymous) WAY to filter out serious people from bad actors doing spray-and-pray hoping they'll make some money, or get that job, by weaponizing AI bots. You can't rely on honor systems and a high trust society on the anonymous open internet, you need to financially gatekeep to save yourself and your sanity, and make sure the honest serious people you want to engage with don't end up drowning in the noise of the scammers and unscrupulous opportunists. But we can't shut ourselves down just because we refuse to apply solutions to AI slop DDoS.
      • goalieca 5mo ago
        The bots spam even when there's no bug bounty program. The emails start out with "I received $500 for a similar reported on another site"
        • autoexec 5mo ago
          Thankfully the number of beg bounties I've seen has been stable so far. Maybe they're just devoting most of their time on the places that openly promise money.
      • nathanielks 5mo ago
• booleandilemma 5mo ago
  Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. So all we have to do is write code without reading or understanding it! Larry Wall was right all along!
  • duskdozer 5mo ago
    Exactly! They should have set [your agentic AI toolkit could be here!] loose on these issues and 100x'd their output, all while actually shipping fixes to these issues instead of closing them. These Luddites are going to be left in the dust as AI is here to stay!
• Neywiny 5mo ago
  I was (almost) just that guy for one PR. Removed something like 20% or more of the codebase by leveraging the libraries and external tools we already had in use better, but it meant almost every single thing we were doing had to use the library function instead of the one we wrote. But assuming you have good regression tests and linters, so you know the code works and it's not terrible, the review should be more about overall high level quality instead of poring over every character to check correctness. It was still a pain to review, though
  • jt2190 5mo ago
    You’re not an example of what we’re taking about here. Congratulations! A better example would be if you’d changed the behavior of the library as you did this work, and the library changes introduced hard-to-detect bugs across the application.
    • wg0 5mo ago
      Yes exactly. the GP isn't what we are talking about it and huge PR isn't what we are talking about either. PR can be huge that's OK. For example, codebases that moved from Python 2 to Python 3 would have had huge PRs but the cognitive load was well understood.
  • triceratops 5mo ago
    Admirable effort. But why did you have to do it in one PR?
    • stronglikedan 5mo ago
      > almost every single thing we were doing had to use the library function instead of the one we wrote
      • triceratops 5mo ago
        Why not proceed file-by-file or directory by directory?
• limaoscarjuliet 5mo ago
  "[...] bottleneck isn't in writing the code. It is in reading and understanding the code". 100% agreed! Furthermore, the more code is generated by AI, the fewer people will actually understand it!
  • CharlesW 5mo ago
    Generally, software engineers already have little to no understanding of the code that's actually being executed. We're so used to high- and higher-level abstractions like C, Go, Python, and JavaScript that we forget that we're already working with mostly-deterministic symbolism in a process that more closely resembles invoking magic spells than writing machine code. One more level of abstraction is not the end of software engineering.
    • dogleash 5mo ago
      To the extent that's true, it's already a problem plaguing the profession. I wouldn't advocate for using different tools, but everyone should be able to reason about the machine instructions underlying their code. Both in the immediate sense of the assembly a simple function turns into, and the tricks language runtimes use to enable their neat features. The attitude that things are magic is poison. There is a difference between feeling confident something is comprehensible and not yet needing to go learn it, vs resigning to a position of powerlessness.
      • ijk 5mo ago
        I agree in principle, but every time I run a debugger on modern C++ it makes it clear that, rather than being a simple and cutesy transformation, "compiler optimization" is actually black magic.
        • skydhash 5mo ago
          It’s not. You “only” have to learn about computer architecture and computation theory. Meaning a lot of maths /s
    • 5mo ago
• nixon_why69 5mo ago
  Context is everything for massive PRs. If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". So the question is, what's the context of the massive PR and how should it be handled? * Mature product making money, intermediate engineer just refactored everything so it's "better"? Shut the fuck up, kindly please, you will have to demonstrate that you understand why things are this way and why it's better before we even have this conversation. * Greenfield dev, trusted engineer getting from 0 -> 1 on something big? Maybe it shouldn't be held up in committee for 2 weeks. Maybe most objections will be superficial stylistic concerns. Obviously there are many other contexts and these are 2 extremes in a multi-dimensional space. But if the process is "we litigate every line", then that's just not an innovative place to be. Yes, most PRs should be small, targeted, easy to review and tied to a ticket but if you're innovating? By definition it's a little different.
  • dogleash 5mo ago
    > If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". That's just cope to avoid learning how to turn a big change into a well organized patch series.
    • nixon_why69 5mo ago
      In retort, that's just doubling down that everything should always be average and plodding. I'm not saying one shouldn't learn how to stage large changes into a mature codebase. Sometimes the overhead is very worth it, maybe most times if you're close to the profit center of a faang. But one should understand multiple ways of working, for different situations.
      • dogleash 5mo ago
        If you can't be arsed to prepare your code for review because it's such a buzzkill to your velocity, why are you even reviewing then? Just push to main. I'm not being snarky. I put different review standards in place for different repos on my team. Sometimes the standard is no standard. Push to main. Figure it out later.
• satvikpendem 5mo ago
  I don't understand why one wouldn't just auto reject big PRs and tell them to make smaller ones. Sounds like it's a communication and social problem, not a technological one. Even with AI, just tell it to make smaller self contained PRs. I do this with Claude or GPT models and they do just fine.
  • xienze 5mo ago
    > Even with AI, just tell it to make smaller self contained PRs. Do you want one big PR or 100 small ones? You can't escape the sheer volume of code it's going to produce.
    • tcoff91 5mo ago
      I want a set of smaller ones if it's practical.
    • satvikpendem 5mo ago
      100 small ones for sure. There could be a way to auto reject new PRs from an author if they have X open ones unreviewed.
  • sparklingmango 5mo ago
    Power dynamics. Usually the person making the giant PRs is the one with all the sway. An earlier-career engineer is unlikely to push back against that level of influence.
    • satvikpendem 5mo ago
      It can be a company wide policy rather than trying to target a single individual even if the outcome is that they are targeted. This is something that should be addressed to them through a manager etc or if not, it's time to leave while they ruin the product over time.
      • pdimitar 5mo ago
        This "you should leave" thing is a very boring and tired take and it should be said regularly that almost no engineer can afford it nowadays. Beautiful theory, but only that.
• Rover222 5mo ago
  The reality is somewhere in the middle. Features are shipping 2x to 5x faster at a lot of organizations, with solid code still being produced and reviewed. Anyone trying to suggest that AI hasn't sped up quality code production is just insisting on keeping their head in the sand, IMO.
  • esafak 5mo ago
    They're just working at companies with mature products where people are in meetings all day -- they say so! Startups very much want to crank shit out faster.
    • Rover222 5mo ago
      Startups that don't leverage AI are just getting crushed and/or not funded.
  • hunterpayne 5mo ago
    I predict a golden age for security is coming soon to those organizations. Dude, we can all literally see your code crumbling in our web browsers.
    • ofjcihen 5mo ago
      For people like me it’s very much already here
    • Rover222 5mo ago
      okay dude, or maybe you're out of the loop
• anilakar 5mo ago
  Without AI, both writing and reading code are bottlenecks. How many times have you reviewed your old code and been appalled at the terrible quality? You personally created slop; it's no different from GenAI output except that a human had to spend precious time crafting it. You likely were indeed bottlenecked by your ability to churn out code that you just had to get to work, for one reason or another. The real issue is in the asymmetry when one party can use automation to create more code than another party can possibly manually verify.
• yoz-y 5mo ago
  With AI everybody gets to be “that guy” now.
• gwbas1c 5mo ago
  > Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. No, it's that quite literally the PR submissions are SPAMmed. Whoever made them is acting like a SPAMmer, sending out lots of garbage and hoping it sticks. IE, they're not doing their part in reviewing what the AI found and generated.
  • ethanrutherford 5mo ago
    So you agree. Unless you're using some definition of "reviewing" which somehow doesn't involve "reading and understanding".
    • gwbas1c 5mo ago
      No, reading and understanding is not the bottleneck. Whoever is running the AI is spamming instead of doing the actual work. IE, they are just pushing their work onto the people who would review legitimate submissions.
• weinzierl 5mo ago
  My whole career I yearned for green field projects but somehow predominantly worked on existing grown code bases and legacy projects. That naturally meant reading and understanding more code than writing. Sometimes my LOC count was even negative, and I was proud of that accomplishment. Now with AI I write even less and I've given up on the dream to gain fulfillment that way. The ability to quickly understand large amounts of code from questionable sources, be them machine or human, should hopefully stay valuable until my retirement, especially when supported by AI? What do you think?
  • ethanrutherford 5mo ago
    Statistically speaking, most codebases are brownfield. Without joining a startup, working on a greenfield project is actually a pretty rare treat. And deleting code is wonderful. I'd go as far as to say lines removed is more often than not more valuable than lines added; every line that's no longer in the codebase is code you no longer have to understand or care about. So long as functionality remains intact, of course. The problem, as I see it, with prolific use of AI to generate code is that it goes in the exact opposite direction. More and more code is bolted on top of existing code, more and more edge-cases, patch-ups, workarounds, etc. accumulate, the codebase grows and grows. In the end, no matter how good you are at understanding "code from questionable sources", you're still a human being. The AI can generate new code at rates several orders of magnitude faster than you can injest and understand it, and when your meat brain becomes exhausted, the machine does not tire. From a business perspective, your employer will weigh their options: they can wait for you to interpret the code and generate good code (whether by hand or by machine + human review).. Or they can just keep pulling the lever on the slot machine until it works well enough to sell. And for the business exec just looking for the fastest path to paydirt, I'm afraid the latter option is going to look way more appealing.
  • pkulak 5mo ago
    Personally, and this is just my wild guess; I think almost no one is _really_ going to learn to code again. That's not a slight on the next generation or anything; I wouldn't know how to code right now if LLMs existed 25 years ago. I love coding, but it's the _result_ that's the real accomplishment. The journey a bit... but having the result always just sitting there, ready to grab with no effort, is too much temptation to resist. And as this goes on, folks who can run an LLM _and_ understand/criticize/rework/re-prompt are just going to get more and more scarce. Even using an LLM in my preferred style, where you guide the model through a long series of small steps, will fade away.
• CodeMage 5mo ago
  > Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. The people AI evangelists often say "typing" instead of "writing code", because they don't really understand -- or it's not lucrative for them to acknowledge -- what makes writing code hard. We don't just write code to be executed by machines, we also write it to be read by humans. Code reviews, debugging, future changes -- all of these things involve reading and understanding the code someone wrote. And until we have an AI that we can actually hold responsible for its actions, we can't delegate the understanding to it.