Live data from Hacker News

Gemini 2.5 Pro Preview

developers.googleblog.com

581–590 of 728 posts

Re: Gemini 2.5 Pro Preview

#581

Earlier quoted context omitted.

> no amount of prompting will get current models to approach abstraction and architecture the way a person does I find this sentiment increasingly worrisome. It's entirely clear that every last human will be beaten on code design in the upcoming years (I am not going to argue if it's 1 or 5 years away, who cares?) I wished people would just stop holding on to what amounts to nothing, and think and talk more about wha…

I code with multiple LLMs every day and build products that use LLM tech under the hood. I dont think we're anywhere near LLMs being good at code design. Existing models make _tons_ of basic mistakes and require supervision even for relatively simple coding tasks in popular languages, and its worse for languages and frameworks that are less represented in public sources of training data. I am _frequently_ having to t…

You're using them in reverse. They are perfect for generating code according to your architectural and code design templete. Relying on them for architectural design is like picking your nose with a pair of scissors - yeah technically doable, but one slip and it all goes to hell.

Re: Gemini 2.5 Pro Preview

#582

Earlier quoted context omitted.

[flagged]

We have a very successful company that has been running 30 years, with developers across 6 countries. We just make sure we hire developers who know that theyre here to do a job, on our terms, for which they will get paid, and its our way or the highway. If they dont like it, they dont have to stay. However, through doing this we have maintained a standard that our competitors fail at, partly because they spend their…

Wow, you are really projecting the image a wonderful person to work for.

I don't doubt you are successful, but the mentality and value hierarchy you seem to express here is something I never want to have anything to do with.

Re: Gemini 2.5 Pro Preview

#583

Earlier quoted context omitted.

You don't care but that's what the market is paying you for. You aren't just replacing developers, you are replacing yourself. Cheaper organisations will be able to compete with you which couldn't before and will drive your revenue down.

That might be the case if we were an organisation that resisted change and were not actively pursuing reducing our staff count via AI, but it isnt. In the AI era our company will thrive because we are no longer constrained by needing to find a specific type of human talent that can build the complicated systems we develop.

So what will happen once most/all your staff is replaced with AI? Your clients will ask the fundamental question: what are we paying you for? You are missing the point that the parent comment raises: LLMs are not only replacing the need for your employees, they are replacing the need for you.

Re: Gemini 2.5 Pro Preview

#585

Earlier quoted context omitted.

You don't care but that's what the market is paying you for. You aren't just replacing developers, you are replacing yourself. Cheaper organisations will be able to compete with you which couldn't before and will drive your revenue down.

That might be the case if we were an organisation that resisted change and were not actively pursuing reducing our staff count via AI, but it isnt. In the AI era our company will thrive because we are no longer constrained by needing to find a specific type of human talent that can build the complicated systems we develop.

You are no longer constrained by that but so are your competitors.

Your developers weren't just a cost but also a barrier to entry.

Re: Gemini 2.5 Pro Preview

#586

Earlier quoted context omitted.

> no amount of prompting will get current models to approach abstraction and architecture the way a person does I find this sentiment increasingly worrisome. It's entirely clear that every last human will be beaten on code design in the upcoming years (I am not going to argue if it's 1 or 5 years away, who cares?) I wished people would just stop holding on to what amounts to nothing, and think and talk more about wha…

I code with multiple LLMs every day and build products that use LLM tech under the hood. I dont think we're anywhere near LLMs being good at code design. Existing models make _tons_ of basic mistakes and require supervision even for relatively simple coding tasks in popular languages, and its worse for languages and frameworks that are less represented in public sources of training data. I am _frequently_ having to t…

> I code with multiple LLMs every day and build products that use LLM tech under the hood. I dont think we're anywhere near LLMs being good at code design.

I too use multiple LLMs every day to help with my development work. And I agree with this statement. But, I also recognize that just when we think that LLMs are hitting a ceiling, they turn around and surprise us. A lot of progress is being made on the LLMs, but also on tools like code editors. A very large number of very smart people are focused on this front and a lot of resources are being directed here.

If the question is:

Will the LLMs get good at code design in 5 years?

I think the answer is:

Very likely.

I think we will still need software devs, but not as many as we do today.

Re: Gemini 2.5 Pro Preview

#587
> We’ve seen developers doing amazing things with Gemini 2.5 Pro, so we decided to release an updated version a couple of weeks early to get into developers hands sooner. Today we’re excited to release Gemini 2.5 Pro Preview (I/O edition).

What's up with AI companies and their model naming? So is this an updated 2.5 Pro and they indicate it by appending "Preview" to the name? Or was it always called 2.5 Preview and this is an updated "Preview"? Why isn't it 2.6 Pro or 2.5.1 Pro?

Re: Gemini 2.5 Pro Preview

#588

Earlier quoted context omitted.

I code with multiple LLMs every day and build products that use LLM tech under the hood. I dont think we're anywhere near LLMs being good at code design. Existing models make _tons_ of basic mistakes and require supervision even for relatively simple coding tasks in popular languages, and its worse for languages and frameworks that are less represented in public sources of training data. I am _frequently_ having to t…

> I code with multiple LLMs every day and build products that use LLM tech under the hood. I dont think we're anywhere near LLMs being good at code design. I too use multiple LLMs every day to help with my development work. And I agree with this statement. But, I also recognize that just when we think that LLMs are hitting a ceiling, they turn around and surprise us. A lot of progress is being made on the LLMs, but a…

Good code design requires good input. And frankly humans suck at coding, so it will never get good input.

You can’t just train a model on the 1000 github repos that are very well coded.

Smart people or not, LLM require input. Or it’s garbage in garbage out.

Re: Gemini 2.5 Pro Preview

#589

Earlier quoted context omitted.

[flagged]

We have a very successful company that has been running 30 years, with developers across 6 countries. We just make sure we hire developers who know that theyre here to do a job, on our terms, for which they will get paid, and its our way or the highway. If they dont like it, they dont have to stay. However, through doing this we have maintained a standard that our competitors fail at, partly because they spend their…

Have you ever hired anyone for their expertise, so they tell you how to do things, and not the other way around? Or do you only hire people who aren't experts?

I don't doubt you have a functioning business, but I also wouldn't be surprised if you get overtaken some day.

Re: Gemini 2.5 Pro Preview

#590

Earlier quoted context omitted.

I've had the opposite experience. Despite trying various prompts and models, I'm still searching for that mythical 10x productivity boost others claim. I use it mostly for Golang and Rust, I work building cloud infrastructure automation tools. I'll try to give some examples, they may seem overly specific but it's the first things that popped into my head when thinking about the subject. Personally, I found that LLMs…

> I use it mostly for Golang and Rust I'm starting to suspect this is the issue. Neither of these languages are in the top 5 languages so there is probably less to train on. It'd be interesting to see if this improves over time or if the gap between the languages become even more intense as it becomes favorable to use a language simply because LLMs are so much better at it. There are a lot of interesting discussions…

Typescript/Java are pretty much the GOATs of LLM codegen, because they have strong type systems and a metric fuck ton of training code. The main problem with Java is that a lot of the training code is Java 6-8, which really poisons the well, so honestly I'd give the crown to Typescript for best LLM codegen language.

Python is good because of the sheer volume of training data, but the lack of a strong type system means you can't have a cycle of codegen -> typecheck -> codegen be automated, and you have to get the LLM to produce tests and run those, which is mostly fine but not as efficient.

Post reply on HN