11-18% of time spent in coding is still very high number I think. For a large org with lots of process and risk aversion, this number could be as low as 5%. Even for 14%, the 10x improvement could mean 86+(14/10) => 87.4/100 => 12.6% overall time saved.
Eight Myths on Software Engineering and GenAI
41–50 of 269 posts
Re: Eight Myths on Software Engineering and GenAI
#42>On my visits to the Bay Area, I would ask AI researchers or interns why they are doing their current research or projects, when in a year or three agentic LLMs could probably do them; This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around th…
> I, as the human, still have to do the thinking as Claude still 'can't jump' I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down. I agree LLMs are not good at abduction but very few humans are either and very few jobs/tasks require it. I can't talk for researchers jobs though. But perhaps fewer researchers would be desired by these labs (not none).
> I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down
Don't worry, I'm sure you'll hit your goal of zero thinking soon!
Re: Eight Myths on Software Engineering and GenAI
#43Earlier quoted context omitted.
> I, as the human, still have to do the thinking as Claude still 'can't jump' I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down. I agree LLMs are not good at abduction but very few humans are either and very few jobs/tasks require it. I can't talk for researchers jobs though. But perhaps fewer researchers would be desired by these labs (not none).
> I agree LLMs are not good at abduction but very few humans are either I, too, am glad that few humans seem good at abduction.
And I hope LLMs don't get better at it.
Re: Eight Myths on Software Engineering and GenAI
#44Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 different versions of the same thing and choose, etc.
Re: Eight Myths on Software Engineering and GenAI
#45Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 diffe…
So you're suggesting that coding will take more of the PRD phase?
Re: Eight Myths on Software Engineering and GenAI
#46>On my visits to the Bay Area, I would ask AI researchers or interns why they are doing their current research or projects, when in a year or three agentic LLMs could probably do them; This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around th…
AI has made 'jumps' in demanding fields like leading mathematical research and has made advancements in AI research itself. Is now a good time to start a maths career? Is there a field of research (yours?) which is inherently (more) AI proof?
Btw, I think the discussion of Einstein's career in the paper you link is historically wrong in many respects, particularly the argument about 'weak signal'. Einstein was in fact working on some of the most mainstream and widely discussed problems in physics of the day, he is admired for the creativity of his solutions to those problems, and much of his work built incrementally on ideas and breakthroughs that came (long) before (as all research does).
Article suggests that a central motivation of Einstein's work was resolving action-at-a-distance in Newtonian mechanics - yet Maxwell introduced the same Lagrangian field theories for electromagnetism we use today 50 years earlier to solve the same problem for Farraday's laws of electromagnetism. Similar wave equations existed even earlier. Heaviside in 1893 extended this technique to gravity (matching 'weak field' GR) 20 years earlier. So this is perhaps the one aspect of gravity that had actually already been solved before Einstein. Authors might be conflating his work on action-at-a-distance in QM.
Einstein's GR extended the linear 'weak field' understanding of gravity to include the non-linear self-referential case where masses themselves create gravity. This was mathematically incredibly difficult but was necessary precisely because SR's mass energy equivalence created so many strong signals that were unresolved. For example: if finite energy is mass, then mass changes as objects accelerate past a large mass like a start, and hence their propagation in space could not be explained by linear EM style field equations. Many such considerations were causing very 'strong signals' in SR, and there were analogous problems in QM atomic models being developed at the same time.
SR was also a solution to a problem that was actively being worked by many of the leading physicists of the day. SR actually does match Newtonian mechanics for a single observer - it resolves contradictions in the case of separate observers, by allowing them to assign different values to the speeds, masses, etc of objects such that each object appears to follow Newtonian mechanics for each observer. Again, this was necessary because of a lot of contradictions related to the behavior of light that had been well-known for ~20 years at the time.
Personally, I don't consider this kind of reasoning to be beyond the capabilities of future LLMs (even current LLMs if the task was broken into technical rather than philosophical problems). Personally, I doubt that such problems could stand open for 20+ years waiting for a creative genius to solve them in the modern world.
And don't get me started on the philosophy.
Re: Eight Myths on Software Engineering and GenAI
#47Earlier quoted context omitted.
> I, as the human, still have to do the thinking as Claude still 'can't jump' I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down. I agree LLMs are not good at abduction but very few humans are either and very few jobs/tasks require it. I can't talk for researchers jobs though. But perhaps fewer researchers would be desired by these labs (not none).
> I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down Don't worry, I'm sure you'll hit your goal of zero thinking soon!
Cognitive offloading is delegating to the AI and still owning the answer. Cognitive surrender is when the AI’s output quietly becomes your output and there is nothing you feel is left to check. For software engineers the line between the two moves under your feet most days, and most of us are crossing it without noticing.
Re: Eight Myths on Software Engineering and GenAI
#48Earlier quoted context omitted.
Yeah, this seriously drives me nuts. That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore. There are engineers whose jobs g…
> That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. How are you going to prompt the LLM or validate its output if you don't understand the requirements?
Your PM can write the ticket, and your QA can test the output.
Re: Eight Myths on Software Engineering and GenAI
#49I don't understand Myth 1 (Developers Spend Most of Their Time Writing Code). They quote a study in which developers report to spend 11-14% of their day coding. The rest is stuff like solution design and meetings. The insinuation is that AI can at most automate 14% of your day. The problem with this argument is that once you have code, some (not all) of the precursors to code go away.
Okay. Show me the evidence that AI has an impact on productivity when doing design work. Or reducing meeting load. My own experience is that AI doesn't tighten the design cycle, and in fact might extend it by encouraging gold plating.
From the patterns I have seen people would tend to use the time to build demo's using AI instead of design and then have a back and forth on the demo itself. One has to consider the fact that demo's look more convincing/complete and give an impression that the design decision has been made. In some ways, how agile got rid of the need for explicit & detailed documentation, the AI created demo's will cut the requirements of high level designs too.
Re: Eight Myths on Software Engineering and GenAI
#50Earlier quoted context omitted.
Yeah, this seriously drives me nuts. That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore. There are engineers whose jobs g…
> That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. How are you going to prompt the LLM or validate its output if you don't understand the requirements?
In some number of cases, the business partner who would have passed you the requirements will just generate the code themselves.. I’m shocked shin some engineers don’t see a massive disruption coming..