Yes this 100%. Every person i speak with who is excited about MCP is some LinkedIn Guru or product expert. I'm yet to encounter a seriously technical person excited by any of this.
The problem isn’t having a standard way for agents to branch out. The problem is that AI is the new Javascript web framework: there’s nothing wrong with frameworks, but when everyone and their son are writing a new framework and half those frameworks barely work, you end up with a buggy, fragmented ecosystem.
I get why this happens. Startups want VC money, established companies then want to appear relevant, and then software engineers and students feel pressured to prove they’re hireable. And you end up with one giant pissing contest where half the players likely see the ridiculousness of the situation but have little choice other than to join party.
I have found MCPs to be very useful (albeit with some severe and problematic limitations in the protocol's design). You can bundle them and configure them with a desktop LLM client and distribute them to an organization via something like Jamf. In the context I work in (biotech) I've found it a pretty high-ROI way to give lots of different types of researchers access to a variety of tools and data very cheaply.
I believe you, but can you elaborate? What exactly does MCP give you in this context? How do you use it? I always get high level answers and I'm yet to be convinced, but i would love this to be one of those experiences where i walk away being wrong and learning something new.
Sure, absolutely. Before I do, let me just say, this tooling took a lot of work and problem solving to establish in the enterprise, and it's still far from perfect. MCPs are extremely useful IMO, but there are a lot of bad MCP servers out there and even good ones are NOT easy to integrate into a corporate context. So I'm certainly not surprised when I hear about frustrations. I'm far from an LLM hype man myself.
Anyway: a lot of earlier stages of drug discovery involve pulling in lots of public datasets, scouring scientific literature for information related to a molecule, a protein, a disease, etc. You join that with your own data and laboratory capabilities and commercial strategy in order to spot opportunities for new drugs that you could maybe, one day, take into the clinic. This is traditionally an extremely time consuming and bias prone activity, and whole startups have gone up around trying to make it easier.
A lot of the public datasets have MCPs someone has put together around someone's REST API. (For example, a while ago Anthropic released "Claude for Life Sciences" which was just a collection of MCPs they had developed over some popular public resources like PubMed).
For those datasets that don't have open source MCPs, and for our proprietary datasets, we stand up our own MCPs which function as gateways for e.g. running SQL queries or Spark jobs against those datasets. We also include MCPs for writing and running Python scripts using popular bioinformatics libraries, etc. We bundle them with `mcpb` so they can be made into a fully configured one-click installer you can load into desktop LLM clients like Claude Desktop or LibreChat. Then our IT team can provision these fully configured tools for everyone in our organization using MDM tools like Jamf.
We manage the underlying data with classical data engineering patterns, ETL jobs, data definition catalogs, etc, and give MCP-enabled tools to our researchers as front end concierge type tools. And once they find something they like, we also have MCPs which can help transform those queries into new views, ETL scripts, etc and serve them using our non-LLM infra, or save tables, protein renderings, graphs, etc and upload them into docs or spreadsheets to be shared with their peers. Part of the reason we have set it up this way is to work through the limitations of MCPs (e.g. all responses have to go through the context window, so you can't pass large files around or trust that it's not mangling the responses). But also we do this so as to end up with repeatable/predictable data assets instead of LLM-only workflows. After the exploration is done, the idea is you use the artifact, not the LLM, to intact with it (though of course you can interact with the artifact in an LLM-assisted workflow as you iterate once again in developing a yet another derivative artifact).
Some of why this works for us is perhaps unique to the research context where the process of deciding what to do and evaluating what has already been done is a big part of daily work. But I also think there are opportunities in other areas, e.g. SRE workflows pulling logs from Kubernetes pods and comparing to Grafana metrics, saving the result as a new dashboard, and so on.
What these workflows all have in common, IMO, is that there are humans using the LLM as an aid to dive understanding, and then translating that understanding into more traditional, reliable tools. For this reason, I tend to think that the concept of autonomous "agents" is stupid, outside of a few very narrow contexts. That is to say, once you know what you want, you are generally better off with a reliable, predictable, LLM-free application, but LLMs are very useful in the prices of figuring out what you want. And MCPs are helpful there.
This is fascinating. I really appreciate the length reply.
How do you handle versioning/updates when datasets change? Do the MCPs break or do you have some abstraction layer?
What's your hit rate on researchers actually converting LLM explorations into permanent artifacts vs just using it as a one-off?
Makes sense for research workflows. Do you think this pattern (LLM exploration > traditional tools) generalizes outside domains with high uncertainty? Or is it specifically valuable where 'deciding what to do' is the hard part?
Someone else mentioned using Chrome dev tools + Cursor, I'm going to try that one out as a way to convince myself here. I want to make this work but I just feel like I'm missing something. The problem is clearly me, so I guess i need to put in some time here.
I'll give you a short reply, as another person who finds MCP very useful. I think a big gap is that MCP's are often marketed as "taking actions" for you, because that's flashy and looks cool in the eyes of laymen. While most of their actual value is the opposite, in using them to gather information to take better non-MCP actions. Connecting them to logs, read-only to (e.g. mock) databases, knowledge bases, and so on. All for querying, not for create/update/delete.
> How do you handle versioning/updates when datasets change?
For data MCPs, we use remote MCPs that are served over an stdio bridge. So our configuration is just mcp-proxy[0] pointed at a fixed URL we control. The server has an /mcp endpoint that provides tools and that endpoint is hit whenever the desktop LLM starts up. So adding/removing/altering tools is simply a matter of changing that service and redeploying that API. (Note: There are sometimes complications, e.g. if I change an endpoint that used to return data directly, but now it writes a file to cloud storage and returns a URL (because the result is to large, i.e. to work around the aforementioned broken factor of MCP) we have to sync with our IT team to deploy a configuration change to everyone's machine.)
I have seen nicer implementations that use a full MCP gateway that does another proxy step to the upstream MCP servers, which I haven't used myself (though I want to). The added benefit is that you can log/track which MCPs your users are using most often and how they are doing, and you can abstract away a lot of the details of auth, monitor for security issues, etc. One of the projects I've looked at in that space is Mint MCP, but I haven't used it myself.
> What's your hit rate on researchers actually converting LLM explorations into permanent artifacts vs just using it as a one-off?
Low. Which in our case is ideal, since most research ideas can be quickly discarded and save us a ton of time and money that would otherwise be spent running doomed lab experiments, etc. As you get later in the drug discovery pipeline you have a larger team built around the program, and then the artifacts are more helpful. There still isn't much of a norm in the biotech industry of having an engineering team support an advanced drug program (a mistake, IMO) so these artifacts go a long way given these teams don't have dedicated resources.
> Do you think this pattern (LLM exploration > traditional tools) generalizes outside domains with high uncertainty?
I don't know for sure, as I don't live in that world. My instinct is: I wouldn't necessarily roll something like this out to external customers if you have a well-defined product. (IMO there just isn't that much of a market for uncertain outputs of such products, which is why all of the SaaS companies that have launched their integrated AI tools haven't seen much success with them.) But even within a domain like that, it can be useful to e.g. your customer support team, your engineers, etc. For example, one of the ideas on my "cool projects" list is an SRE toolkit that can query across K8s, Loki/Prometheus, your cloud provider, your git provider and help quickly diagnose production issues. I imagine the result of such an exploration would almost always be a new dashboard/alert/etc.
I use only one MCP, but I use it a lot: it's chrome devtools. I get Claude Code to test in the browser, which makes a huge difference when I want it to fix a bug I found in the browser - or if I just want it to do a real world test on something it just built.
I have found MCPs helpful. Recently, I used one to migrate a site from WordPress to Sanity. I pasted in the markdown from the original site and told it to create documents that matched my schemas. This was much quicker and more flexible than whipping up a singular migration tool. The Sanity MCP uses oAuth so I also didn’t need to do anything in order to connect to my protected dataset. Just log in. I’ll definitely be using this method in the future for different migrations.
When the inexperienced move to become rare and on the frontier, sure they get an advantage but the field doesn’t get the benefit, they do. This is why the early days of Node were awful. So many jr devs (that’s being generous, mostly designers with a base knowledge of js) were jumping from writing front ends to entire stacks. They won, the stacks lost.
Experience matters and it’s an advantage, that’s not a reason for new people not to compete but rather one to understand that context and use it to help them grow.
Couldn’t agree more (but frustratingly due to HN’ shitty mobile experience i downvoted this, sorry!)
In a past life i used to complain that people only praised my work after i fucked up and subsequently fixed it. I’d go month on month of great execution and all I’d hear would be complaints, but as soon as i “fixed” a major issue, i was a hero.
I’ve learn that setting appropriate incentives is the hardest part of building an effective organization.
I had to mention this in an early startup, when I did some firefighting, and the biz people were praising that. I said I wanted to set a culture in which engineering was rewarded for making things just happen and work, not for firefighting.
A nice thing about early startups is that it's the easiest time to try to set engineering culture like this on a good track. Once you start hiring people, they will either cement elements of whatever culture you're setting, or they'll bring a poor culture with them.
(My current understanding, if you find your culture has been corrupted with a clique/wolfpack of mercenary ex-FAANG people, or a bunch of performative sprint theatre seatwarmers, is that you either have to excise/amputate everywhere the cancer has spread, or accept that you're stuck with a shit culture forever.)
> (My current understanding, if you find your culture has been corrupted with a clique/wolfpack of mercenary ex-FAANG people, or a bunch of performative sprint theatre seatwarmers, is that you either have to excise/amputate everywhere the cancer has spread, or accept that you're stuck with a shit culture forever.)
You just described my last job. It went from one of the most productive (and I mean we fucking SHIPPED - quality work, usually the first time around), engaging, and fun places I've ever worked to a place where a new VP would sit in every single group's sprint planing, retros, and standups and interject if we deviated one iota from a very orthodox scrum framework. The engineering turnover was pretty much 95% within a year, with only the most junior people remaining because they didn't really know better to move on. Work slowed, tech debt ballooned, but OMFG were the product managers happy because they were also allowed in every step of the way.
Work slowed to a crawl, too. Eventually a private equity firm swooped in and made things even worse...
That sounds like there was some top-down, or mid-down, culture changing (which can easily happen as a company tries to build a hierarchy, drawing from outside).
Another risk is bottom-up culture. You could have your existing leadership the same, but you start hiring ICs who bring their culture with them, and you fail to nurture the desired culture.
I think one of the concerns with early startups is if the early engineering leadership hasn't gotten respect and buy-in from the CEO, as the company grows. If the early engineering leadership was doing unusually solid work and culture, but the CEO thinks they are just random fungible commodities, and that now it's time for a different mode, then CEO will probably urinate away all that corporate strength very quickly.
The company was founded by an ideas guy (not technical) and the first hire was the (technical) CTO. The CTO set the initial excellent engineering culture. The way I saw it, the founder had no choice but to defer to the engineering team in the beginning because without them there was no future. However, once we started bringing in revenue, the pressure and interference from the CEO started to mount until the CTO essentially got tired of it and moved on. The CEO wasn't even a terrible person, but had trouble dealing with pushback (and I've chatted with him after and he admits he was wrong - he was also in his early 20s during all of this).
The CTO position was never replaced and, I'm not making this up, the head of product was made VP of engineering. An external director of engineering was brought in to implement business metrics, tracking, process etc that all answered to this VP of product. Any sense of balance was removed and the highest ranking advocates for tech were team leads. The VP of Eng wasn't necessarily evil, but couldn't or wouldn't do anything that got in the way of business and couldn't convey how important it was to sometimes take a step back.
We did alright financially, though. We had an exit (not enough for me to retire, but at 45 I essentially don't have to save for it anymore if that makes sense) and moved on, but the slowed down development meant that some other new ideas were only finally gaining traction when the PE firm gobbled us up. I personally think had things remained as they were, or changed (as companies do need to as they grow) more positively, we'd have been much more successful.
I've had an iphone for 15 years. I mean, it's fine...i just wish there was incentive for durability and sustainability v's replace it every 12-24 months. I guess sustainability concerns at Apple ends at ensuring their stock price is sustainable.
What do you do with your phones that it doesn't last more than 24 months?
I've had only two iPhones for almost 11 years. An iphone 6s and currently an iPhone 13 mini there entire time.
They're solidly reliable
The camera iterates significantly every other year. My kid plays baseball, from little league to now high school ball. The pictures I can take on my iPhone are incredible. (I’d do the same thing with a Pixel or Samsung if I was a Android person)
My work phones are typically on a 4-5 year cycle. I’m currently carrying a 12 or 13 pro. I would have upgraded early for USB-C with that phone, but MagSafe is good enough.
Same here. Had a 7 for years. Upgraded to a 13. So far not felt the need to upgrade.
I compare this to when I had an 3G and the 4 came out. The gap between the two was so huge that I upgraded quickly. Reminded me of how quickly PCs evolved in the 90s.
You have kids? I want pictures At random points throughout the day while doing random things, every day. I’m not a photographer that keeps a SLR camera on me at all times.
I don't see the need to photograph every second of their life, 50 years old over here, having gone through times when taking kids pictures were limited to 12, 24 and 36 attempts.
My only two iPhones have been the iPhone SE 2016, and the 13 mini.
I miss the SE but the 13 mini is really nice too. It's a shame because the SE is still perfectly capable of running most software I use on a phone, but that software has just gotten more inefficient over time.
Apple says they stopped producing minis because they didn't sell. It seems they sold relatively better than the Air, and pretty much everyone I know who still uses a device of "13" or earlier generation, is on a mini. That's about 5 people just in my social circle still on a 13 Mini, and 0 people on any other non-Mini 13th or older generation. I reckon that's the real reason they stopped making them, people who use them, are willing to stay with their phones for much longer periods. Could also be that they break less due to being smaller.
Yes. The kind of people who use iPhone minis are generally more reasonable and won't spent too much time doomscrolling on them or overusing them for random stuff (like pretending you are a good photographer).
In that sense they are very bad customers because they won't upgrade for social status reason or just novelty. They actually need to come up with something that is worthwhile, which is pretty hard.
That being said, I'm pretty sure many of those users would upgrade if they could keep the small format and make it more reasonably affordable by removing most of "useless" stuff. It seems like they tried that with the air (no multiple cameras, no multiple speakers) but they made it too big and went with thinness for feeling points. They could have just kept it reasonably sized (under 6") and designed the internals in the same way while keeping it flat but not too thick.
I think Apple is a bit lost because their design focus too much on looks/feelings and social status points. They lack the focus that Apple products used to have, this is what made them interesting: deceptively simple in presentation but actually providing everything that you need without going crazy on the gimmicks.
As it is, one wonders why he should go with an iPhone. They are just chasing specs sheet points, trying to maximise the amounts of stuff they can put on the phone in order to create the appearance of "value". At this game they get destroyed by competitors like Samsung and even more the Chinese. Before, one could argue for an iPhone because of the CPU lead or the software but nowadays none of those things really matters or can even be considered an advantage.
Apple will keep selling lot's of iPhone because they are still somewhat the "hip" brand and people really don't like to change habits. But they are going to need to provide more value in the long term. Since the high-end doesn't meaningfully evolve anymore, brands have started a price war and Apple will definitely need to adapt if it doesn't want to have its crown stollen. In the US they have some time, but I think they are already losing ground in the EU and China has clearly stopped caring about their devices.
I have the 22 SE and I suspect I’ll get 3 more years out of it before they EOL it. I would have bought the 16e if it wasn’t such a blatant money grab. Touch ID is going to be hard to give up
I'm kind of the opposite, I would never want to go back to Touch ID. It's so nice that you can set your notifications to be private by default, but the contents will be revealed when you glance at the phone.
I think it really matters how you store your phone as to the usefulness of Touch ID. Someone storing it in their front pocket will have it always available in an ideal position to unlock on grab, whereas someone storing it anywhere that doesn't lock it in a position like that is going to see less benefit of being able to unlock the thing as they grab it.
I just had to get a new phone old was a 2020 SE (Previous was a 6S plus) so 5 years.
The new phone is FaceId ioty is much less reliable than touch id. With touch it just fails if I have wet hands or in cold weather with gloves, faceId fails in many places.
Agreed, pulling the phone out of a pocket with my thumb on the home button and having it unlocked and ready to use by the time I look at it is is ideal.
Much better than having to pull it out, hold in in a way that it can see my face, then swipe up, then wait for the stupid animation at the top of the screen to finish and the actual unlock to occur and then finally be able to use the device.
Since 2010: 3GS, 6S and now an SE. All of them were dropped, submerged and generally knocked around. The SE fell off the top of a moving vehicle. I do use an Otter case.
Similar -- I'm currently nursing a 13 mini (the lightning port barely works, so I'm on magsafe). and before that I had an iPhone XS I think -- that one I managed to break the screen (the only time I've ever done that, I dropped it in a metal elevator). I replaced the screen but it was never the same.
So I didn't go 11 years on two models, more like 7 years or so. But I'm definitely not on the two-years-and-upgrade plan.
I had a 12 mini for 5 years, it was a really lucky year to buy one because of MagSafe. The lightning ports just don’t hold up as well as the rest of it.
Thanks, I did. Maybe I just have linty pockets? It can charge sometimes if I press the lightning cable end down or up just so. And that gets a little better maybe if I toothpick it, but only maybe and only for one or two times?
I’ve had a 6+ and a 12. I guess 18 should be coming along soon, maybe it will be with an upgrade. But the 12 still feels… I dunno, really quite good.
I’ve also had it in a case the whole time, if I opened a box and found this thing I don’t think I’d be unhappy. Other than the inevitable gunk that gets in the speakers and the charging hole, it could be new…
I guess it is a race between battery health (80%) and update incompatibility, to see what will kill the thing.
Its a threesome! (cringe) Yes, our iPhones really get pounded on and end up with so much street credibility as they look like they were shot with bullets but they keep working.
I think a more charitable reading is that OS upgrades left their devices barely usable to the point of having to be replaced. I'm not a big Apple person so don't have personal experience but have heard similar stories from multiple other people, that OS upgrades wrecked the old devices they were still using.
Two iPads, an iPod Touch and an iPhone of mine have been made unusable by OS updates. If Apple had made the cutoff just one OS version sooner, then they would still feel snappy to use. They’re not actually bricked, but completely unusable and essentially e-waste.
Honestly I wish i knew. I find the battery really gets substantially worse after 12-18 months, and eventually I'm living with it plugged in to avoid getting caught with it low when I'm out.
Recently I dropped my phone (while in a case) and now there's a black spot on the screen.
Stuff like this. I live a life between a lot of DIY work and software dev, so I'm physically probably rougher on it than most, but also a heavy user of the technology too.
In the real world I don't know anyone replacing their phone every 24 months. Usually people keep a phone for 3-4 years and then it gets given to kids/someone else for another few years usage. I doubt any significant number of people are chucking their 1 year old iphone in a draw to sit unused after they get the next one.
What you describe as pro-consumer is only pro to some consumers, because they come with extra weight, size, and case compromises that every consumer would non-optionally be stuck with. I’d agree with you if we were in some no-compromise world or if there there was significant evidence that Apple wasn’t designing these phones within an inch of their pan-dimensional budget (size, weight, durability, hardware, battery life, etc) and leaving a bunch of room on the table, but that’s an unfounded and easily disproven theory.
I would be okay with being "stuck" with a replacement battery and a 3.5mm jack. That's a compromise I'd be wiling to take; but at the end of the day it's all about profit.
As PP noted, the tradeoff is vs. making things thinner and more waterproof.
I'm OK with wireless charging and using the USB port for audio or other purposes, though occasionally I want to use wired Ethernet or Thunderbolt displays at the same time as wired audio, and I also use a wired charge/audio dongle as a car adapter (though there are wireless chargers available.)
You might be willing to, but the product might be more attractive to millions out there if they didn’t have these items. You can say that is about profit but it is also about making a better product, weighed by what customers want in aggregate.
I know some people (me included) who get a new phone frequently, but it usually works by shifting down devices down the family. E.g. our daughter, my parents, and some of my in-laws all have devices shifted down from person to person.
I'm on my fourth iPhone in 13 years and have never replaced a phone because of anything related to physical damage. I'd still be on my third but T-Mobile offered such a large trade-in value for my 2020 SE that upgrading was the same price as replacing the battery.
The issue with batteries on older iPhones isn't even replacing the battery. Apple will do it for like $80 bucks or so out of warranty. That's WAY cheaper than a new phone.
But every new OS version manages to use more CPU and GPU and burn down that battery faster even if it's brand new, since the older chips have to work harder to run them than they had to work to run the older OSes.
I replaced my battery which was showing around 83% of original capacity last year, in a 3-4 year old phone. I was skeptical of the 83% reported number. Nope. The new battery didn't last much longer, nowhere close to how long it lasted on the OS it shipped with.
(This software-cpu-bloat is not unique to Apple. My Pixel, after 4 years or so, was practically unusable just from the amount of background shit the CPU was doing, compared to when it was new.)
Yes software bloat and lack of optimisation is the problem.
But this is exactly why Apple is full of shit. They pretend to do and know better by forcing updates and locking down your ability to install/manage software as you see fit; yet you do not get any meaningful value in exchange.
All the App Store discourse would be moot if they clearly enforced a minimum software quality but they are way too greedy to actually do that.
So in the end you are subjected to the same software bloat as Android but you just pay more for the device.
Pixels get slow because they have very weak CPUs to begin with. If you had gone with a Samsung the experience would be much better (not too different than that of an iPhone, even though the look is of a different taste).
You make a point, but it’s hard to square valuing sustainability with that kind of personal replacement rate when the supported life is several years. That said, your old phone is either being resold or parted, and and the valuable materials from unusable parts are recovered through disassembly.
If the incentive is for consumers to buy more devices the incentive change.
I think it also has to do with the shift in computing population. It was easy to convince tech people to buy a new OS based on a feature list. When computers became more widely used, it became harder and harder. E.g. when OS X still had paid upgrades, it was very hard to convince non-tech family to buy the update. Buying a new device is easier, because the features are immediately visible to people and carrying a newer devices is also a form of social signaling.
At the same time, the internet became far more hostile and running an OS that has all the security updates is important. So, it's easier to get people to update when the updates are free.
I feel like there are a lot of iPhone features being slept on. Pairing Shortcuts and Apple Intelligence lets a grandma do some powerful work that she could never have done five years ago.
This is absurd. I’ve kept an iPhone 12 for 4 years, only replacing it last month with a 17 Pro.
Throughout that time my 5 year old phone got every OS and security update. And it’ll get the OS update in 2026 as well. So the phone released in 2020 gets software updates till 2027 - 7 years. The main issue that makes people want to upgrade is battery life degrading. Good thing Apple offers cheap and quick battery replacements in store. I replaced my battery at the 2 year mark for a small amount of money and it felt like a new phone.
What more could Apple possibly do to make their devices more sustainable? The processors are insanely overpowered, so they don’t feel slow. The batteries are easy to replace. The software updates are there. Being a bit cynical, Apple only making small incremental changes each year reduces the need to upgrade even further.
If people want to replace their devices every year or two that’s on them, not Apple.
That’s wild. I fell off my garage roof almost 2 weeks back. My wife called the ambulance, they arrived within 20 minutes. We are in rural Ontario, 30 minutes from the nearest hospital, on a dirt road that is privately owned and maintained. I expected over an hour.
I plan to make a trip in to the ambulance hall and fire hall this week and say thanks. I am ok, fractured vertebrae, but honestly i just am so grateful for the public service they provide.
Growing up in Australia 1 cent pieces were gone before i knew what money was. Coming to Canada in 2009 on a trip, i was shocked to see them. They were annoying and instantly drove me crazy, but i felt bad throwing them out. I threw them out anyway, helping reduce inflation
I’ve been criticized for this by my coworkers in the past, but I strongly believe that this is generally true and has been for quite a while. Developers, myself included, like to think their code is special, set in stone and going to last forever. Most the code we write struggles to live a few years yet we treat all of it like it’s going to last forever. I’ve been an advocate for flipping that and treating it like our code will not last long, and when we identify the components that will, going back and optimizing them.
I’m pretty confident that most developers, again including myself, just really enjoy knowing something is done well. Being able to separate yourself from the code and fixate solely on the outcomes can sometimes get me past this.
Interesting, i always see attempts to make these types of database tools as super interesting but then I think about all the undocumented edge cases that can come up and they scare me off.
Many many years ago I worked on a monitoring tool that itself needed to be highly available, and we needed a solution like this. Ever since that time I've done everything in my power to avoid it.
What are the real world cases you built this for? And how can someone like me who has been bruised by past experiences get comfortable with it?
Just a guess, but some of the undocumented edge cases you saw might be explored in this blog from one of our software engineers, Shaun Thomas. It's all about conflict resolution & avoidance in PostgreSQL, in general: https://www.pgedge.com/blog/living-on-the-edge
Getting some examples of real-world cases to share and will comment back with them ASAP; in the meantime, would you mind sharing what undocumented edge cases you came across and what solutions you explored to handle them? It would help with sharing super relevant use cases :-)
I tried to escape this world as quickly as possible, realizing how horrible it was, but the largest issue I ran into was around IO. Creating an environment that was highly tolerant to fault while having little to no replication delay meant checking in on the master database frequently. Keeping in mind this was around 2010 I found that the IO load on these databases was substantially larger than any database that i had ever worked on before. Things like available file handlers and other related performance problems came up more frequently than I’ve ever experienced before and frankly more frequently than I’ve ever experienced since.
If I was to summarize it, I would just say the performance characteristics were not something I was used to experiencing and often they would surprise me when they occurred, which meant having a good quality of a while for running this application was very challenging.
Typical use case would be a anyone who has global presence, but serves users in particular geos (think AWS): you want a global user database but it’s soooo convenient to be able to join with regional data in a single query.
Yeah, 3.5 was good when it came out but frankly anyone reviewing AI for coding not using sonnet 4.1, GPT-5 or equivalent is really not aware of what they've missed out on.
The second point is more incentive than AI capability i'd argue. Your point presumes that Open Source === Good. I'm not sure that's how all of society feels, unfortunately, so even if AI can do it at some point...it might not choose to.
reply