Eight Myths on Software Engineering and GenAI
221–230 of 269 posts
Re: Eight Myths on Software Engineering and GenAI
#222Earlier quoted context omitted.
> So you mean AI will be useful for any general job without lots of training for those jobs? How about new tasks? I'm pretty sure we will solve this issue. Either already through World Models or another architecture. It could also be, that we just need a 10 or 100 Trillion Parameter model to match so many generic ways of solving tasks and keeping the concept in the LLMs 'head' to solve it that it will just emerge wit…
> I'm pretty sure we will solve this issue. Either already through World Models or another architecture. Please elaborate. How? With which technique? Currently the only path forward is to feed more data and tweak for specific situations (fitting, basically). How does that help in the general case or in new situations with current tecchnology (LLMs, concretely). Noatter how far you get, this is not a general or reliab…
Reinforcement learning can just solve things even if they are new. It doesn't understand how a tool works? Give it a vm with the tool, a thousand agents and let it discover it automatically.
Use the thumbs up/down emoji + chat analysis when a customer is unhappy, feed that to a RL Loop.
The AI Researchers though work on World Models, grounding the AI and letting it simulate. It can do the simulation in parallel (unlimited) and choose what is best.
> I think you miss how much tacit knowledge and judgement there is inside the brains of each of us that an LLM is not capable of.
But thats my problem. Soooo many do not have this even as senior developers.
> Now you have a bug. You do not know even where to start. Thisis theprice to payfor speed, as usual: technical debt.
Yeah now i just ask the LLM to describe to me the bug. Works very well.
> Now you tell me you put three agents to talk and burn 2000 usd in tokens. Great! Is the final solution better than what you would have achieved? Not sure at all.
This is the thing. It only needs to make the team 10-30% better to compensate token budget with one work collegue. We have reached this level in my opinion already. Choosing a head count vs. choosing tokens.
But it becomes cheaper and easier and better. So you will not just be able to do ith with 3 agents but with 20, 50 or 100.
It will be better if your team is an avg team. It will be worse if you have a high profile team, for now. But man our industry has such a weird broad quality spectrum.
> TBH I am not into agents bc I do not trust a tool sniffing all my code and for copyright concerns
In worst case, my team always do code reviews, I do a code review on an ai instead of a human and adjust the harness or the infos the ai can access. I can actually work on making this workflow better and then i can clone it or spin it up for every single PR. For a human? I have to train them and they might leave.
But there are plenty of cases were code doesn't matter. Researchers write a lot of random shitty uggly code as long as it does what it does, it doesn't matter. I have scripts for small tasks, we have microservices which do one thing because it is a tech stack we only need for one use case.
Re: Eight Myths on Software Engineering and GenAI
#223Earlier quoted context omitted.
Also people tend to forget that LLMs still just work on compressed data... Where are the MAJOR breakthroughs? Where is all the "crazy" AI output going? Software seemed to degrade in quality a lot in the recent years. All "improvements" LLMs go through are simply improvements on how to burn more tokens out of my pockets given that Claude now want an actual browser extension to "visually" confirm small changes every ti…
LLM don't work on 'compressed data'. LLM compress data into their latent space which allows them to become general. They learn the concept of things and how to do them because this is better compression than learning concepts one by one. Which means, if an LLM 'learns' the concept of a poem, it can put everything into the formad of a poem instead of learning a billion poems.
When anthropic looked at how an LLM does addition it found it had some mental math heuristics that might or might not always work. The LLM hadn't learned the concept of addition. It had learned some heuristics that might work for some numbers. The result is that LLM's cannot add numbers reliably because they have not learned the concept of addition.
Re: Eight Myths on Software Engineering and GenAI
#224Re: Eight Myths on Software Engineering and GenAI
#225This feels about right as an average across project cycles and different types of companies, and is the same type of number I've suggested here before.
The obvious conclusion is that even if AI reduced coding time to zero, then it would only reduce software development time by that 14%.
Of course AI may be used for other aspects of the job as well as coding, but on the flip side any serious use of AI requires a human in the loop to give work to the AI, steer the AI, assess the output, etc.
It's interesting that this 14% figure is close to Uber's choice to limit AI spend to 10% of developers salary. I wonder where that Uber number came from?
Another rather startling datapoint on the perceived value of AI comes from Microsoft who are also adopting budgeted AI usage, and are looking for "outcomes that move the needle". Their budget guidelines apparently refer to (current? targeted?) per-developer AI usage of "hundreds of dollars a month to a few thousand dollars in tokens".
https://www.techradar.com/pro/tokenmaxxing-is-not-what-we-ar...
Re: Eight Myths on Software Engineering and GenAI
#226Earlier quoted context omitted.
Once you've seen the AI not make mistakes like that a few dozen times you start to trust it not to mess that up in the future.
Is this really a rational strategy for something whose nature is to be right most of the time and then spectacularly wrong a much lesser amount of the time?
Re: Eight Myths on Software Engineering and GenAI
#227Earlier quoted context omitted.
I review the code that matters - anything security adjacent or that's an API that will be used by other code in the future. I don't review code that either works or doesn't - most HTML and CSS layout code for example. There I test it on desktop and mobile and commit it if it works. Ditto for stuff that's simple. A JSON endpoint that runs a SQL query and returns some JSON? If it works and a glance at the tests looks O…
lol I think you’re setting yourself up for failure. Why? Just because something works doesn’t necessarily know you the boundaries of it. What scale does it work for? Will it crumble under load in prod? It works but allows cross tenant access (security issue) because security checks weren’t in the location you thought… Dangerous!
Re: Eight Myths on Software Engineering and GenAI
#228Earlier quoted context omitted.
Mind sharing some names or something else we can learn about?
https://martinfowler.com/articles/harness-engineering.html https://developers.redhat.com/articles/2026/04/07/harness-en... https://loiane.com/2026/04/harness-engineering-missing-layer... https://devarch.ai/
Re: Eight Myths on Software Engineering and GenAI
#229Earlier quoted context omitted.
> And I say that as someone who uses Claude Code in complex environments almost hourly; I, as the human, still have to do the thinking as Claude still 'can't jump' [1] and I have seen no evidence that they (or similar AI, any time soon) will 'jump' like a human brain does. Sure it can, turn up the "temperature" a bit. There's this notion that human "jumping" is magic. It's not. It's all based on inputs. Including unr…
> The hard part is discrimination: whether a given mental jump is "creative" or "insane" That's what they mean by LLM's can't jump. They mean it can't make a creative jump. Their example is Einstein's Theory of Relativity - It's not a random jump.
Re: Eight Myths on Software Engineering and GenAI
#230It's a huge piece of shit and if I wasn't forced to use it at work I would never use it.
It writes dumb, throw-away code and adds thousands of dollars/developer in costs. All this crazy code that we're adding to our projects will come back to bite us in the future, there's no way it won't.