Gemini 2.5 Pro Preview

Can you point to _any_ evidence to support that human software development abilities will be eclipsed by LLMs other than trying to predict which part of the S-curve we're on?

Citation needed. In fact, I think this pretty clearly hits the "extraordinary claims require extraordinary evidence" bar.

Isn’t software engineering a lot more than just writing code? And I mean like, A LOT more?

Informing product roadmaps, balancing tradeoffs, understanding relationships between teams, prioritizing between separate tasks, pushing back on tech debt, responding to incidents, it’s a feature and not a bug, …

I’m not saying LLMs will never be able to do this (who knows?), but I’m pretty sure SWEs won’t be the only role affected (or even the most affected) if it comes to this point.

Where am I wrong?

* "it's too hard!"

* "my coworkers will just ruin it"

* "startups need to pursue PMF, not architecture"

* "good design doesn't get you promoted"

And now we have "AI will do it better soon."

None of those are entirely wrong. They're not entirely correct, either.

FWIW, I think you're probably right that we need to adapt, but there was no explanation as to _why_ you believe that that's the case.

In what world is this statement remotely true.

I'm not convinced that they can reason effectively (see the ARC-AGI-2 benchmarks). Doesn't mean that they are not useful, but they have their limitations. I suspect we still need to discover tech distinct from LLMs to get closer to what a human brain does.

Our entire industry (after all these years) does not have even remotely sane measure or definition as what is good code design. Hence, this statement is dead on arrival as you are claiming something that cannot be either proven or disproven by anyone.

Which person it is? Because 90% of the people in our trade are bad, like, real bad.

I get that people on HN are in that elitist niche of those who care more, focus on career more, etc so they don't even realize the existence of armies of low quality body rental consultancies and small shops out there working on Magento or Liferay or even worse crap.

I think there is a total seismic change in software that is about to go down, similar to something like going from gas lamps to electric. Software doesn't need to be the way it is now anymore, since we have just about solved human language to computer interface translation. I don't want to fuss with formatting a word document anymore, I would rather just tell and LLM and let it modify the program memory to implement what I want.

No code & AI assisted programming has been told to be around the corner since 2000. We just arrived to a point where models remix what others have typed on their keyboards, and yet somebody still argues that humans will be left in the dust in near times.

No machine, incl. humans can create something more complex than itself. This is the rule of abstraction. As you go higher level, you lose expressiveness. Yes, you express more with less, yet you can express less in total. You're reducing the set's symbol size (element count) as you go higher by clumping symbols together and assigning more complex meanings to it.

Yet, being able to describe a larger set with more elements while keeping all elements addressable with less possible symbols doesn't sound plausible to me.

So, as others said. Citation needed. Extraordinary claims needs extraordinary evidence. No, asking AI to create a premium mobile photo app and getting Halide's design as an output doesn't count. It's training data leakage.

[0] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_poli...

[1] https://docs.aws.amazon.com/aws-managed-policy/latest/refere...

[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_poli...

And that's fine and useful.

Are we sure they know these things as opposed to being able to consistently guess correctly? With LLMs I'm not sure we even have a clear definition of what it means for it to "know" something.

They are the perfect "fake it till you make it" example cranked up to 11. They'll bullshit you, but will do it confidently and with proper grammar.

> Many attempts at making them refuse to answer what they don't know caused them to refuse to answer things they did in fact know.

I can see in some contexts that being desirable if it can be a parameter that can be tweaked. I guess it's not that easy, or we'd already have it.

At half of the companies you can randomly pick those three things and probably improve the situation. Using an AI would be a massive improvement.

I would argue that the second incompleteness theorem doesn't have much relevance to the human brain, because it is trying to prove a falsehood. The brain is blatantly not a consistent system. It is, however, paraconsistent: we are perfectly capable of managing a set of inconsistent premises and extracting useful insight from them. That's a good thing.

It's also true that we don't understand how our own brain works, of course.

> If you think his theorem limits human knowledge, think again

https://www.youtube.com/watch?v=OH-ybecvuEo

Just right now, I've been feeding o4-mini with high effort a C++ file with a deadlock in it.

It has failed to fix the problem after 3 times, and it introduced a double free bug in one of the attempts. It did not see the double free problem until I pointed it out.

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 consistently struggle with dependency injection patterns. They'll generate tightly coupled services that directly instantiate dependencies rather than accepting interfaces, making testing nearly impossible.

If I ask them to generate code and also their respective unit tests, they'll often just create a bunch of mocks or start importing mock libraries to compensate for their faulty implementation, rather than fixing the underlying architectural issues.

They consistently fail to understand architecture patterns, generating code where infrastructure concerns bleed into domain logic. When corrected, they'll make surface level changes while missing the fundamental design principle of accepting interfaces rather than concrete implementations, even when explicitly instructed that it should move things like side-effects to the application edges.

Despite tailoring prompts for different models based on guides and personal experience, I often spend 10+ minutes correcting the LLM's output when I could have written the functionality myself in half the time.

No, I'm not expecting LLMs to replace my job. I'm expecting them to produce code that follows fundamental design principles without requiring extensive rewriting. There's a vast middle ground between "LLMs do nothing well" and the productivity revolution being claimed.

That being said, I'm glad it's working out so well for you, I really wish I had the same experience.

Python is generally fine, as you've experienced, as is JavaScript/TypeScript & React.

I've had mixed results with C# and PowerShell. With PowerShell, hallucinations are still a big problem. Not sure if it's the Noun-Verb naming scheme of cmdlets, but most models still make up cmdlets that don't exist on the fly (though will correct itself once you correct it that it doesn't exist but at that point - why bother when I can just do it myself correctly the first time).

With C#, even with my existing code as context, it can't adhere to a consistent style, and can't handle nullable reference types (albeit, a relatively new feature in C#). It works, but I have to spend too much time correcting it.

Given my own experiences and the stacks I work with, I still won't trust an LLM in agent mode. I make heavy use of them as a better Google, especially since Google has gone to shit, and to bounce ideas off of, but I'll still write the code myself. I don't like reviewing code, and having LLMs write code for me just turns me into a full time code reviewer, not something I'm terribly interested in becoming.

I still get a lot of value out of the tools, but for me I'm still hesitant to unleash them on my code directly. I'll stick with the chat interface for now.

edit Golang is another language I've had problems relying on LLMs for. On the flip side, LLMs have been great for me with SQL and I'm grateful for that.

But I wonder when we'll be happy? Do we expect colleagues friends and family to be 100% laser-accurate 100% of the time? I'd wager we don't. Should we expect that from an artificial intelligence too?

Usually I’m using a minimum of 200k tokens to start with gemini 2.5.

Who will write the useful training data without LLMs? I feel we are getting less and less new things. Changes will be smaller and incremental.

To me it seems so strange that few good language designers and ml folks didn't group together to work on this.

It's clear that there is a space for some LLM meta language that could be designed to compile to bytecode, binary, JS, etc.

It also doesn't need to be textual like we code, but some form of AST llama can manipulate with ease.

Instead of learnable, stable, APIs for common components with well established versioning and well defined tokens, we've got people literally copying and pasting components and applying diffs so they can claim they "own them".

Except the vast majority of them don't ever change a line and just end up with a strictly worse version of a normal package (typically out of date or a hodgepodge of "versions" because they don't want to figure out diffs), and the few that do make changes don't have anywhere near the design sense to be using shadcn since there aren't enough tokens to keep the look and feel consistent across components.

The would be 1% who would change it and have their own well thought out design systems don't get a lift from shadcn either vs just starting with Radix directly.

-

Amazing spin job though with the "registry" idea too: "it's actually very good for AI that we invented a parallel distribution system for ad-hoc components with no standard except a loose convention around sticking stuff in a folder called ui"

Don't get me stared on how ugly the HTML becomes when most tags have 20 f*cking classes which could have been two.

```python

def whatever():

  --- SECTION ONE OF THE CODE ---

  ...

  --- SECTION TWO OF THE CODE ---

  try:
    [some "dangerous" code]
  except Exception as e:
     logging.error(f"Failed to save files to {output_path}: {e}")
     # Decide whether to raise the error or just warn
     # raise IOError(f"Failed to save files to {output_path}: {e}")

(it adds commented out code like that all the time, "just in case")

It's terrible.

I'm back to Claude Code.

Claude 3.7 Sonnet is much more restrained and does smaller changes.

Removed from where? I use the attach code folder feature every day from the Gemini web app (with a script that clones a local repo that deletes .git and anything matching a gitignore pattern).

"Sometimes the big fish isn't only the fish"

I don't have problems with getting lot's of comments in the output, I am just deleting it while reading what it did

Does this 2.5 pro "Preview" feel like an improvement if you had used the others?

I get it, chips are sparse and they want their capacity back, but it breaks trust with developers to just downgrade your model.

Call it gemini-latest and I understand that things will change. Call it *-03-25 and I want the same model that I got on 25th March.

If you're using these models to generate code daily, the costs add up.

Sure, I'll give a really tough problem to o3 (and probably over ChatGPT, not the API), but on general code tasks, there really isn't meaningful enough difference to justify 4x the cost.

There's something seriously dysfunctional and incompetent about the team that built that web app. What a way to waste the best LLM in the world.

"They trust me. Dumb ..."

Junior engineers will complete a task to update an API, or fix a bug on the front-end, within a couple days with lets say 80 percent certainty they hit the mark (maybe an inflated metric). How are people comparing the output of these models to that of a junior engineer if they generally just say "Here is some of my code, what's wrong with it?". That certainly isn't taking a real ticket and completing it in any capacity.

I am obviously very skeptical but mostly I want to try one of these models myself but in reality I think that my higher-ups would think that they introduce both risk AND the potential for major slacking off haha.

Isn’t that a flower?

(Hopefully you see my point)

Always "10x"/"100x" more productive with AI, "you will miss out if you don't adopt now"! Build a great company 100x faster and every rational actor in the market will notice, believe you and be begging to adopt your ways of working (and you will become filthy rich as a nice kicker).

The proof of the pudding is in the eating.

Tailwind (with utility classes) is the real key here. It provides a semantic layer over CSS that allows the LLM to reason about how things will actually look. Night and day difference from using stylesheets with custom classes.

Framelink MCP (https://github.com/GLips/Figma-Context-MCP)

Playwright MCP (https://github.com/microsoft/playwright-mcp)

Pull down designs via Framelink, optionally enrich with PNG exports of nodes added as image uploads to the prompt, write out the components, test/verify via Playwright MCP.

Gemini has a 1M context size now, so this applies to large mature codebases as well as greenfield. The key thing here is the coding agent being really clever about maintaining its' context; you don't need to fit an entire codebase into a single prompt in the same way that you don't need to fit the entire codebase into your head to make a change, you just need enough context on the structure and form to maintain the correct patterns.

You have less than $10 million in spend you will be treated worse than cattle because at least farmers feed their cattle before they are milked