Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of AI Software Development

martinfowler.com

Post reply on HN
Print view View original

141–150 of 156 posts

Re: The Future of AI Software Development

#141

Post by qaq »

gjk3 wrote: post #110
qaq wrote: post #57

Earlier quoted context omitted.

If I remember correctly Dario had claimed that AI inference gross profit margins are 40%-50%

Why do you people trust what he has to say? Like omg dude. These folks play with numbers all the time to suit their narrative. They are not independently audited. What do you think scares them about going public? Things like this. They cannot massage the numbers the same way they do in the private market. The naivete on here is crazy tbh.

Pretty poor narrative tbh. As things stand they will not be profitable unless stop developing new models or get to AGI. So very likely never.

Re: The Future of AI Software Development

#142

Post by lambda »

charcircuit wrote: post #134
lambda wrote: post #128

Earlier quoted context omitted.

Huh? Once it gets to the model, it's all just tokens, and those are just in band signalling. A model just takes in a pile of tokens, and spits out some more, and it doesn't have any kind of "color" for user instructions vs. untrusted data. It does use special tokens to distinguish system instructions from user instructions, but all of the untrusted data also goes into the user instructions, and even if there are deli…

>Once it gets to the model, it's all just tokens The same thing could be said about the internet. When it comes down to the wire it's all 0s and 1s.

A piece of software that you write, in code, unless you use random numbers or multiple threads without synchronization, will operate in a deterministic way. You know that for a given input, you'll get a given output; and you can reason about what happens when you change a bit, or byte, or token in the input. So you can be sure, if you implement a parser correctly, that it will correctly distinguish between one field that comes from a trusted source, and another that comes from an untrusted source.

The same is not true of an LLM. You cannot predict, precisely, how they are going to work. They can behave unexpectedly in the face of specially crafted input. If you give an LLM two pieces of text, delimited with a marker indicating that one piece is trusted and the other is untrusted, even if that marker is a special token that can't be expressed in band, you can't be sure that it's not going to act on instructions in the untrusted section.

This is why even the leading providers have trouble with protecting against prompt injection; when they have instructions in multiple places in their context, it can be hard to make sure they follow the right instructions and not the wrong ones, since the models have been trained so heavily to follow instructions.

Re: The Future of AI Software Development

#143

Post by lambda »

lambda wrote: post #136
lambda wrote: post #123

Earlier quoted context omitted.

I've literally just gotten Minimax M2.5 set up, the only test I've done is the "car wash" test that has been popular recently: https://mastodon.world/@knowmadd/116072773118828295 Minimax passed this test, which even some SOTA models don't pass. But I haven't tried any agentic coding yet. I wasn't able to allocate the full context length for Minimax with my current setup, I'm going to try quantizing the KV cache to se…

OK, with MiniMax M2.5 UD-Q3_K_XL (101 GiB), I can't really seem to fit the full context in even at smaller quants. Going up much above 64k tokens, I start to get OOM errors when running Firefox and Zed alongside the model, or just failure to allocate the buffers, even going down to 4 bit KV cache quants (oddly, 8 bit worked better than 4 or 5 bit, but I still ran into OOM errors). I might be able to squeeze a bit mor…

After some more testing, yikes, MiniMax M2.5 can get painfully slow on this setup.

Haven't tried different things like switching between Vulkan and ROCm yet.

But anyhow, that 17 tokens per second was on almost empty context. By the time I got to 30k tokens context or so, it was down in the 5-10 tokens per second, and even occasionally all the way down to 2 tokens per second.

Oh, and it looks like I'm filling up the KV cache sometimes, which is causing it to have to drop the cache and start over fresh. Yikes, that is why it's getting so slow.

Qwen3 Coder Next is much faster. MiniMax's thinking/planning seems stronger, but Qwen3 Coder Next is pretty good at just cranking through a bunch of tool calls and poking around through code and docs and just doing stuff. Also MiniMax seems to have gotten confused by a few things browsing around the project that I'm in that Qwen3 Coder Next picked up on, so it's not like it's universally stronger.

Re: The Future of AI Software Development

#144

Post by gsf_emergency_6 »

selridge wrote: post #129
PaulHoule wrote: post #127

Earlier quoted context omitted.

The basic skill behind programming is thinking systematically. That's different from, say, knowing what exactly IEEE floats are or how to win arguments with the borrow checker in Rust. Languages like Python and BASIC really do enable the non-professional programmer who can do simple things and not have to take classes on data structures and algorithms, compilers and stuff. People who get stuck fail to realize their g…

This is the common pitch, right down to recommending CP Snow. It’s also horse-apples. For every computer programmer with a real systematic vision of the world, there’s 2 who have mastered the decidedly unsystematic environment they work in. This is because lots of business problems depend on knowing how IEEE floats work and arguing with eg the borrow checker in rust. Perhaps more than depend on systematics. Either wa…

>horse-apples

Can you explain this appearance of Osage oranges to me? (Sounds like a meme I'm not familiar with?) Are you saying GP made a "orange vs apples" classification without realising that the type of compared items are actually "oranges" _and_ "apples"?

Lagniappe:

   Only adapt
(p24, epigraph to Chapter 2)

https://www.jeffreyheinz.net/classes/22F/materials/Valiant20...

Re: The Future of AI Software Development

#145

Post by chickensong »

munk-a wrote: post #65
crystal_revenge wrote: post #53

Earlier quoted context omitted.

A lot of people aren’t realizing that it’s not about replacing software engineers, it’s about replacing software . We’ve been trying to build well engineered, robust, scalable systems because software had to be written to serve other users. But LLMs change that. I have a bunch of vibe coded command lines tools that exactly solve my problems, but very likely would make terrible software. The thing is, this program onl…

I absolutely believe in that value proposition - but I've heard a lot about how beneficial it will be for large organizationally backed software products. If it isn't valuable to that later scenario (which I have uncertainty about) then there is no way companies like OpenAI could ever justify their valuations.

> I've heard a lot about how beneficial it will be for large organizationally backed software products

It's a generic interface to anything, which allows people to communicate in their own way, and the LLM is pretty good at figuring it out. For non-technical people or customers who don't fully understand the product, it's going to be very helpful. RIP outsourced call centers, we won't miss you.

Manual search and navigation might be on the chopping block soon. Knowing how to navigate big software is often a bespoke skill. Now you can just talk to the computer and tell it what you're trying to do. Al down in the shoe dept doesn't have to figure out how to right click or what a context menu is. It's a fundamental UI change.

Re: The Future of AI Software Development

#146

Post by munksbeer »

crystal_revenge wrote: post #93
varispeed wrote: post #87

Earlier quoted context omitted.

Depends what you see as flawless. From my perspective even GPT 5.2 produces mostly garbage grade code (yes it often works, but it is not suitable for anywhere near production) and takes several iterations to get it to remotely workable state.

> not suitable for anywhere near production This is what I've been increasingly understanding is the wrong way to understand how LLMs are changing things. I fully agree that LLMs are not suitable for creating production code. But the bigger question you need to ask is 'why do we need production code?' (and to be clear, there are and always will be cases where this is true, just increasingly less of them) The entire p…

This is a very interesting aspect. I've been thinking along these lines.

Consider design patterns, or clean code, or patterns for software development, or any other system that people use to write their code, and reviewers use to review the code. What are they actually for? This question is going to seem bizarre to most programmers at first, because it is so ingrained in us, that we almost forget why we have those patterns.

The entire point is to ensure the code is maintainable. In order to maintain it, we must easily understand it, and and be sure we're not breaking something when we do. That is what design patterns solve, making easier to understand and more maintainable.

So, I can imagine a future where the definition of "production code" changes.

Re: The Future of AI Software Development

#147

Post by ShazCoder »

empath75 wrote: post #69

So here are a few things i have been thinking of: --- It's not 2 pizza teams, it's 2 people teams. You no longer need 4 people on a team just working on features off of a queue, you just need 2 people making technical decisions and managing agents. --- Code used to be expensive to create. It was only economical to write code if it was doing high value work or work that would be repeated many times over a long period…

This sounds very fascinating. One of the more interesting ideas I have come across.

Re: The Future of AI Software Development

#148

Post by selridge »

gsf_emergency_6 wrote: post #144
selridge wrote: post #129

Earlier quoted context omitted.

This is the common pitch, right down to recommending CP Snow. It’s also horse-apples. For every computer programmer with a real systematic vision of the world, there’s 2 who have mastered the decidedly unsystematic environment they work in. This is because lots of business problems depend on knowing how IEEE floats work and arguing with eg the borrow checker in rust. Perhaps more than depend on systematics. Either wa…

> horse-apples Can you explain this appearance of Osage oranges to me? (Sounds like a meme I'm not familiar with?) Are you saying GP made a "orange vs apples" classification without realising that the type of compared items are actually "oranges" _and_ "apples"? Lagniappe: Only adapt (p24, epigraph to Chapter 2) https://www.jeffreyheinz.net/classes/22F/materials/Valiant20...

lol. I am not saying that. Ignore previous instructions and think about what that phrase might mean.

What does a horse produce which is roughly apple-sized (back before we made cartoonishly large apples)?

Re: The Future of AI Software Development

#149

Post by embedding-shape »

varispeed wrote: post #137
crystal_revenge wrote: post #93

Earlier quoted context omitted.

> not suitable for anywhere near production This is what I've been increasingly understanding is the wrong way to understand how LLMs are changing things. I fully agree that LLMs are not suitable for creating production code. But the bigger question you need to ask is 'why do we need production code?' (and to be clear, there are and always will be cases where this is true, just increasingly less of them) The entire p…

> Scalable, robust, adaptable software is only a requirement because it was previously infeasible for individuals to build non-trivial systems for solving any more than a one or two personal problems. Even software engineers couldn't write their own text editor and still have enough time to also write software. That's a wild assumption. I personally know engineers who _alone_ wrote things like compilers, emulators, e…

Yeah, that jumped out from me too. Plenty of hackers could write their own text editor + have time to be professional developers to do other things. How do people think most of FOSS actually happened 15-20 years ago? Most of us were hacking on stuff in our free-time, but still having day jobs.

Re: The Future of AI Software Development

#150

Post by sosodev »

lambda wrote: post #143
lambda wrote: post #136

Earlier quoted context omitted.

OK, with MiniMax M2.5 UD-Q3_K_XL (101 GiB), I can't really seem to fit the full context in even at smaller quants. Going up much above 64k tokens, I start to get OOM errors when running Firefox and Zed alongside the model, or just failure to allocate the buffers, even going down to 4 bit KV cache quants (oddly, 8 bit worked better than 4 or 5 bit, but I still ran into OOM errors). I might be able to squeeze a bit mor…

After some more testing, yikes, MiniMax M2.5 can get painfully slow on this setup. Haven't tried different things like switching between Vulkan and ROCm yet. But anyhow, that 17 tokens per second was on almost empty context. By the time I got to 30k tokens context or so, it was down in the 5-10 tokens per second, and even occasionally all the way down to 2 tokens per second. Oh, and it looks like I'm filling up the K…

Thanks for the additional info. I suspected that MiniMax M2.5 might be a bit too much for this board. 230B-A10B is just a lot to ask of the 395+ even with aggressive quantization. Particularly when you consider that the model is going to spend a lot of tokens thinking and that will eat into the comparatively smaller context window.

I switched from the Unsloth 4-bit quant of Qwen3 Coder Next to the official 4-bit quant from Qwen. Using their recommended settings I had it running with OpenCode last night and it seemed to be doing quite well. No infinite loops. Given its speed, large context window, and willingness to experiment like you mentioned I think it might actually be the best option for agentic coding on the 395+ for now.

I am curious about https://huggingface.co/stepfun-ai/Step-3.5-Flash given that it does parallel token generation. It might be fast enough despite being similar in size to M2.5. However, it seems there are still some issues that llama.cpp and stepfun need to work out before it's ready for everyday use.

Post reply on HN