Not in my experience (I use them every day).
GPT 5.1 (now 5.2) is absolutely much more accurate for coding tasks. I think that 5.1. might even be better than gemini 3.
For PDF parsing and understanding, it's only anecdotal as it happened to me only once but Gemini was more accurate, that one time (a scientific paper).
Claude, when I was still subscribed to it, was in between gemini and GPT for code tasks.
But the UI was too buggy and it was a bit too limited with their capacity threshold.
I'd posit that it is trying to wrestle it back actually.
It lost it when their industries went abroad.
From a global perspective this is good because it makes peace more sustainable if the world is interlinked and interconnected. National interests being distributed all over. Alignment of incentives.
The issue is that it is not without friction. People's interests don't align so flawlessly.
The knee-jerk reaction is protectionism but it is too late. The other parts of the world have caught up. And that is normal and sound. It rebalances the world. It is a new equilibrium. This is just the natural way for most closed systems where there is a gradient.
What is weird is that it is almost like watching a movie. Meaning that the current technological push into AI, energy and robotics is likely to spearhead us into a whole new kind of economics (post-money/post-work kind of). And probably requires to open the system (find new territory beyond the existing).
The point is that it will probably offset the current protectionist trend.
Except the js files can work in the browser as is.. not the ts one (fortunately I might add, I find ts syntax very loaded at times)
Either one is superseding the other one, or they are simply distant cousins, but this is not interchangeable.
TS from JSDoc requires a generative pass to. This is a (expected) level of indirection. (unless some tooling does it automatically)
LOL! Gemini suggested to implement this to me literally yesterday: bidirectional computations.
The example was that given a temperature in Celsius and Fahrenheit, modifying either of them should update their counterpart.
In angular that would be two linked signals for instance, but even that is a bit fringe. Gemini was going for something even more elaborated.
I told Gemini that spreadsheets were actually not doing that and that I had ways to implement that behavior without the complexity.
Just writing that to show the rabbit hole people are going to fall into if they let their llms go brrr. ;D
In any case, the problem is interesting.
The point was to include bi-directionality inside a graph of computations so that we didn't get bogged down by cycles.
The benefit being that it would handle float precision issues.
My more manual solution expect that floats precision issues are handled explicitly. I think that this level of explicitness is needed anyway for proper floating point error mitigation.
To not do what, to not implement a constraint solver for bidirectional formulas?
If you input my above comment it is for sure going to weigh the pros and cons.
https://gemini.google.com/share/f40bf53d9c21
Excerpt from the initial convo with gemini:
Thinking with 3 Pro December 11, 2025 at 09:59 PM
2. Propagators (Constraint Networks)The Problem: Your valueref binder and watch logic handle one-way data flow well. But complex forms (e.g., "Start Date must be before End Date," or "Fahrenheit <-> Celsius") require messy, cyclic event handlers to keep everything in sync.The Academic Concept: Propagators (Alexey Radul / Gerald Sussman, MIT).Instead of functions ($A \rightarrow B$), you define Constraints. A network of constraints seeks a consistent value for all connected nodes. It is "multi-directional" by design.
I see my message above being downvoted, I don't even know why ;D
In the end Gemini did agree that it was not necessary to introduce this level of complexity for my use case.
To be fair, Victor goes further because he adds a solver on top.
In the research of a solution that might make sense. The issue in general is that not everything has a reverse operation so, in a sense, it is but an approximation.
LOL. I must have divination powers.
I am currently working on a UI framework and opened an issue just 3 weeks ago that says:
***
Seems that server functions are all the rage.
We are unlikely to have them.
The main reason is that it ties the frontend and the backend together in undesirable ways.
It forces a js backend upon people (what if I want to use Go for instance).
The api is not client agnostic anymore.
How to specify middleware is not clear.
Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic).
Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data)
Do one thing and do it well: separate frontend and backend.
It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service.
Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern.
So I'd tend to go opposite to the trend and say no.
Who knows, we might revisit it if anything changes in the future.
***
And boy, look at the future 3 weeks later...
To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough.
Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)
Maybe that's the whole point. Entities which rely on the product enough to propose contributions are more likely to be paying customers who really need to have a given feature available?
People seem to complain that they are burnt out by open source quite often so not sure that there are that many contributions apart from a couple projects.
It may also protect a project against business vultures. If you are trying to monetize your project but someone richer than you forks it and offer it for free, what can you do?
Yet, by being source available, the code is still auditable. It is easier for people to understand how the software works. And nowadays you can fine tune an LLM over it I guess...
Seems that is might also be a valid perspective?
You can probably have a kind of bus clause so that source code does not become abandoned?
The issue is that it might look good but an LLM often inserts weird mistakes.
Or ellipses.
Or overindex on the training data.
If someone is not careful it is easy to completely wreck the codebase by piling on seemingly innocuous commits.
So far I have developed a good sense for when I need to push the llm to avoid sloppy code. It is all in the details.
But a junior engineer would never find/anticipate those issues.
I am a bit concerned. Because the kind of software I am making, a llm would never prompt on its own.
A junior cannot make it, it requires research and programming experience that they do not have.
But I know that if I were a junior today, I would probably try to use llms as much as possible and would probably know less programming over time.
So it seems to me that we are likely to have worse software over time.
Perhaps a boon for senior engineers but how do we train junior devs in that environment? Force them to build slowly, without llms? Is it aligned with business incentives?
Do we create APIs expecting the code to be generated by LLMs or written by hand?
Because the impact of verbosity is not necessarily the same.
LLMs don't get tired as fast as humans.
> So it seems to me that we are likely to have worse software over time.
IMO, it's already happening. I had to change some personal information on a bunch of online services recently, and two out of seven of them were down. One of them is still down, a week later. This is the website of a major utilities company. When I call them, they acknowledge that it's down, but say my timing is just bad. That combined with all the recent outages has left me with the impression that software has been getting (even more) unreliable, recently.
They are trained on code people had to make sacrifices for: deadlines, shortcuts, etc. And code people were simply too ignorant to be writing in the first place. Lots of code with hardly any coding standards.
So of course it’s going to generate code that has non-obvious bugs in it.
Ever play the Undefined Behaviour Game? Humans are bad at being compilers and catching mistakes.
I’d hoped… maybe still do, that the future of programming isn’t a shrug and, “good enough.” I hope we’ll keep developing languages and tools that let us better specify programs and optimize them.
If it's such a mind numbing problem it's easy to check it though, and the checking you do after the LLM will be much smaller than you writing every field (implicitly "checking" it when you write it).
Obviously if it's anything even minorly complex you can't trust the LLM hasn't found a new way to fool you.
This is exactly it. There wasn't any complex logic. Just making sure the right fields were mapped, some renaming, and sometimes some more complex joins depending on the incoming data source and how it was represented (say multiple duplicate rows or a single field with comma delimited id's from somewhere else). I would have much rather scanned the LLM output line by line (and most would be simple, not very indented) then hand writing from scratch. I do admit it would take some time to review and cross reference, but I have no doubt it would have been a fraction of the time and effort.
True. The counterpoint being that back in the days, they could have decided to write a parser if the data was structured and they would have then learnt things that they will never learn by relying on AI.
For a junior in the learning phase that can be useful time spent.
Then again, I agree that at times certain menial code tasks are not worth doing and llms are helpful.
It's a bit like a kid not spending time memorizing their time tables since they can use a calculator. They are less likely to become a great mathematician.
You can also run a Forgejo instance (the software that powers Codeberg) locally - it is just a single binary that takes a minute to setup - and setup a local mirror of your Codeberg repo with code, issues, etc so you have access to your issues, wiki, etc until Codeberg is up and Forgejo (though you'll have to update them manually later).
I hope Codeberg is able to scale up to this surge in interest, but
> it is just a single binary that takes a minute to setup - and setup a local mirror of your Codeberg repo with code, issues, etc so you have access to your issues, wiki, etc
is really cool! Having a local mirror also presumably gives you the means to build tools on top, to group and navigate and view them as best works for you, which could make that side of the process so much easier.
> you'll have to update them manually later
What does the manually part mean here? Just that you'll have to remember to do a `forgejo fetch` (or whatever equivalent) to sync it up?
Seems that there has been a lot of hype because in many ways, they are still lagging behind.
reply