I would say ALL of science, not just "much" of it. The difference between math and science is that in science, hard reality is the bottom line. No matter how good your model, how much data you have, what p values you get against simulations - hard reality wins everytime. Thats also why the so called soft "sciences" aren't sciences at all: they are not dealing with hard, objective reality at all.
I also believed that, but at least for India, this doesn't work in practice. Unless you atleast do the 25$ pro plan, cloudflare routes even india-to-india, hell, even mumbai-to-mumbai and aws_mumbai-to-cloudflare_mumbai traffic via Marsaille!! Not even Singapore. The unstated reason is that indian transit is expensive, though I fail to believe its cheaper to go from mumbai to marsaille and back to mumbai.
I am guessing the real reason (and at this point I am discounting incompetence - this has been true for years, so they are aware). You switch to the pro plan for the zone and everything now routes within india, 100s of milliseconds of latency saved.
Its even worse for workers and workers AI and embedding search. I found multiple seconds of latency, all vanishing the moment the zone is on pro plan (It seems R2, workers, workers AI - none of them are deployed in an India POP - unconfirmed, of course, cause there is no way to actually communicate with cloudflare).
Now 25$/month isn't much - though it does change calculations compared to "FREE!!" - but I would have liked to know this going in, instead of discovering this after having made the commitment. Seems like a deliberate dark pattern, to force people into the pro plan.
Shame, really - I love the CF stack(workers and DO are just so fantastic to build on), but these shenanigans, plus the utter refusal to provide ANY level of support, keep souring me on them.
> The unstated reason is that indian transit is expensive, though I fail to believe its cheaper to go from mumbai to marsaille and back to mumbai.
IMHO, it's not that hard to believe.
a) Every hosting provider I've looked at prices for charges significantly more for bandwidth from their Indian locations.
b) In the US, transit providers basically never charged different rates for different destinations [1]. In Europe, it's typically rare, sometimes transit to the local incumbent telecom is more, sometimes there's a different rate for Europe or non-Europe, but there won't be a specific destination charge for India, it will be part of a blended rate. Otoh, east Asia often has separate rates for specific nearby countries and India is likely to be one of those...
Transit prices in Europe are pretty low compared to prices in India, so the blended price being less than the India direct price is not surprising to me at all.
[1] gcp premium does charge by destination, but the premium transit price is pretty close to their price for cross location traffic to something near the destination + non-premium traffic from that location... Which is more or less what their premium network egress is.
It's basically that payment flows towards the core of the network, which is Europe and America. If you're the first Indian ISP, you have to pay a European ISP for an upstream connection - they won't pay you. And that persists and becomes "just the way things are done". It can only reverse if there are significant websites in India that Europeans want to access, then the European ISPs will be getting more value than the Indian ones and the Indian ones will be able to demand payment.
Transit in some countries, like India, genuinely is that expensive. Keep in mind it doesn’t cost Cloudflare any more to serve Indian traffic from Marsaille than to serve non-peered French traffic from that colo - they aren’t paying the cost of getting traffic between India and France.
The traffic still has to flow from an india provider to the international leg and back via the domestic provider.
In anycase, then they should document it clearly that they have unacceptable insertion latency in india and the free plan is entirely unusable for india. Instead of advertising '10 pops in india!!'
> The traffic still has to flow from an india provider to the international leg and back via the domestic provider.
Right, but Cloudflare doesn't have to pay for it in that case. If Cloudflare sends you to their Indian POP, then they have to pay their Indian service provider for traffic. If they send you to their France POP, then they have to pay their French ISP for traffic. The Indian provider cannot claim any of Cloudflare's traffic in that case, because the Indian service provider wouldn't have any relationship with Cloudflare
This is very standard for places with high ISP costs, like South Korea and India. You can see a lot of discussion about it online. I agree with you that Cloudflare should be more transparent if / when they make different routing decision for Free/Pro plans based on bandwidth costs, but I don't think their decision itself is unreasonable at all. Indian bandwidth is very expensive.
You would think Cloudflare would be in a position to do something about it, like they did with several cloud services in their Bandwidth Alliance. It would be a win-win-win for networks to interconnect better in India, it just can't happen stepwise because any individual step is a lose for somebody.
> The unstated reason is that indian transit is expensive, though I fail to believe its cheaper to go from mumbai to marsaille and back to mumbai.
Your Indian ISP is paying a French ISP for both directions of that traffic, which makes it cheap at the French end. Were it India-to-India, Cloudflare would have to pay your ISP.
This seems a worsening that seems to have started at Opus 4.8.
When I (was forced to) switched from 4.7 to 4.7, I noticed that 4.8 had a very strong bias against viewing tool output or reading files. It ALWAYS wanted to 'grep' things. So for example, it would run the test suite and grep for 'PASS', thus completely missing the 4 tests that FAILed. Its bias is so strong, that it does this despite explicit instructions to the contrary, and continues to do so even after having noticed its own mistake, in the same (claude code) session.
For editing files, it again seems to prefer writing small python scripts, rather than read the file and rewrite it (even small files, like notes). This again causes it to constantly miss duplications, inconsistencies, etc.
And from 4.8 to 5, it doubled down on this. At this point not moderately-long-horizon task is getting done consistently, due to its pigeon-hole view of the workdir.
1. It writes SO MUCH code, in minutes, that theres no way I as a human can review it.
2. I am not very motivated to read/review this code anyway: it was cheaply written, by some _thing_ that is not going to improve from my feedback.
3. If you DO review it conscientiously , it becomes a never ending thing: you keep finding issue upon issue.
4. If you report the issues for fixes, the fixes normally fix that immediate issue, and typically add another parallel path/another option/another 100-odd lines of code, instead of a structural fix.
5. If the code base is large, and if you let AI write a meaningful amount of code in it, its no longer _your_ code. You lose the depth+width of understanding needed to reason thru things mentally, cause you no longer KNOW enough about the code.
6. If you do review seriously, and either fix things yourself, or have the ai/harness fix the issues for you, the rounds of fixes take so long, if you look back you realize it would have been better to just do it yourself in the first place.
My personal opinion there are really only two choices:
A. If you want to build FAST, using an agent, just let the agent write tests, validations, extensively, have it keep running them (it likes to call them gates), and just let it loose. Give up on the idea that its your code, and that you understand it. The bottom line becomes: does it work, and WHEN it breaks in weird ways, just use the agent to find and fix the issue (probably breaking something else in the process).
B. limit AI use for non trivial, prod-quality projects to limited research, very tiny targeted changes, write most of the code yourself still, and review every line. You won't get much speedup, maybe 20-30%, but it will still be YOUR code, and you will still be able to reason about it.
Route A seems genuinely horrifying to me - maybe not for small and/or helper scripts; but for anything substantial. For anything that bites you or someone else hard when things go bad.
I don’t want a vibe-coded, mass-produced diabetes tracking app, or banking tool, or tax management software. I don’t want a vibe-coded power grid analysis software.
I don’t care if a person’s little, local scripting thing is vibe-coded. I don’t care if an artist’s 0->1 game code is vibe-coded; but that’s not what a lot of the things we’re talking about here really are.
Route A is good for rapid, disposable prototyping. If you ever have a stray thought, “I wonder how this would work if the whole paradigm were turned sideways”, you now have a chance to preview a “working” version of your idea. If you like it, discard the code and reimplement it correctly. In this way, I think it can be a good adjunct to sketches and other lofi prototyping techniques. Just don’t outsource the creative ideation to the LLM, because all you’ll get are the same solutions as everyone else.
Have you seen many of the replies in this thread and others? They’re not doing that. They’re putting it into production code. Their company’s thought leaders are trying to say that review itself is a waste of time, etc.
That’s not “disposable prototyping” that’s whole versions of the codebase written with barely a human in sight.
Route A is what concretely what is behind those "a select few are seeing 100x productivity increases" posts. agents bring enterprise-level engineering to the IC. your average enterprise PM has no idea how the code works either but knows who to call when it breaks or needs a new feature added. the industry split on agentic use lies in how much and to what degree you believe "but AI is different!" in this analogy
You should be the one building the gates then, but those gates should be mechanical and deterministic so the AI doesn’t wprk around them.
Lint rules, type errors, commit lint, anything that tells the AI to stop instead of allowing workarounds.
These are basic: they work for human coders and are typically quick to setup. But gates at this level are far from enough for agentic coding. You need an extensive test suite/e2e suite/benchmark suite. Typically much larger than the code base itself: This is what enables those "i ported bun to rust in a weekend" headlines. Where ever such extensive 'gates', high quality ones, already exist, the agent can do a good job of making things work, cause it can automatically iterate.
But: every hole, every gap in coverage, will be eventually found by the coding agent and 'exploited'. So you need full, extensive coverage.
This suite itself is a LOT of work, much more than what it would be if you only had to worry about human coders. So if YOU are writing the gates yourself, you are going to fall between A and B: you still have a convoluted, unreliable, impossible-to-reason-about prod app, AND it still took you eons to build it cause you spent that time writing the gates. This is no win at all, on either front.
Where gates, extensive ones, help in route A is they can significantly reduce the churn/spinning, fix-x-break-y, to just the parts that are gaps in coverage (which the agent will keep finding at a ridiculous rate). And your work would be to have it ALSO keep filing in those gaps with more tests/etc.
One of the reasons go coding with agents works better than other langs is cause I even include AST based enforcements in my governance suite. Its still route A, but with somewhat more confidence, somewhat less frustration.
I am now looking at 9 to 10x the app code, for non trivial stuff. And this is not just the usual unit/integration/e2e suites too. Extensive deadcode, field use, code shape tests (ast walking) - god objects, 15-param helpers, wrapper-piled-upon-wrapper, badly named (a skill) functions/methods/objects, path-dependent artifacts, etc. There is no way I could have written all this manually.
It doesn't guarentee high quality OR reliability or readability or maintainability, but does reduce churn and makes me feel a bit more confident about deploying route A work product in prod.
Isn't it an age old maxim: democratic governments should remember to not build tools/give them selves powers that they won't want the opposition to be able to use WHEN they come to power.
India really has very deep penetration of 5g, and at very low cost. There might be a rare place that starlink might be needed but really I cannot image starlink having much consumer/retail uptake in india. Not needed, and too expensive. There might be commercial users - offshore rigs etc, but india is too densely populated for there to be many 'truly remote' locations.
India has still not permitted starlink to start ops.
There is a hilarious one in the Indian direct tax (Income tax) code right now:
If your (taxable) income is less than 7L (inr), no tax is assessed.
If your income is greater than 7L, but upto 12L, tax is assessed, but a tax _rebate_ (a discount on payable tax) is granted for the exact amount of tax owed. This means net tax paid till 12L is zero.
But if your income is 12L + 1, this rebate no longer applies, so the entire tax assessed (on the 7L+ income) is now due. This means that a person who earns 12L+1 INR makes ~70K inr less, post-tax, than the person who earns 12L INR.
After complaints, to correct this, they added another layer: If your taxable income is >12L but less than 12L+~70K (the tax thats due), then the maximum tax due is just the amount your income exceeds 12L bye. So you stagnate at the same post-tax salary from 12L to 12L+70K.
Math + real world observation -> science
reply