I am finding the goal of the project at odds with the anti-local approach in the article.
I understand the point about people not wanting to be sysadmins - but surely hosting your Guardian Angel in a AWS data center has its own risks. Imagine how broken you would feel when us-east-1 goes down again.
> While I have found LLMs useful for researching and planning code changes, my attempts at actually making them write code have been quite lackluster. I found them to be slow and expensive to generate, for a mediocre result.
I think this observation is generally true for the kind of problems the author is working on.
But I would not make the leap to avoid using LLMs for any kind of code writing. LLMs do fantastically well in the 95%+ of the code that engineers spend time on. And for those we should leverage the technology.
It is upto us as engineers to figure out when to stop using LLMs. We are smarter than just dumping logs and half dozen specialized markdown files to a LLM and have it figure out solutions.
All this completely ignores the cataclysmic negative externalities, including environmental costs, knowledge atrophy and workforce erosion, accelerated burnout, slop-pollution of the open internet, shifting of power from engineers to management and SAAS corps, and empowerment/enrichment of some of the most morally vacuous people in tech history.
I think we are moving from "can you build this product?" to "do i trust you to support this product?". Software is cheap, trust is a premium.
Developers and companies who put real care into their product will come out on top. A large part of that is going to be, what not to build - something AI agents will always say yes to.
To be fair, was always the case but its only going to be made more apparent as AI scales out.
> I think we are moving from "can you build this product?" to "do i trust you to support this product?". Software is cheap, trust is a premium.
This right here!
I have very little issue with LLM-generated code, my issue is mostly with people throwing codebases over the fence, declaring it the best library/framework/app/platform/whatever and in 3 months I know the repo will say "Last commit 3 months ago".
Some things are "done" and don't need constant updates but most of the "bad" LLM code IMHO is the kind of stuff I know requires dedication (even if an LLM is writing all the code) and commitment to the library/etc for it to succeed.
If all you've done is vibe-coded something and aren't going to support it then I'll just vibe-code my own version tailor-made for my use-case that I can support myself.
I've thought about this a lot in relation to my side-business "could someone vibe code this?" and the answer is absolutely yes they could, but my customers don't come from me throwing code out into the world and walking away. My continued support, handling issues, being on-site for events (I make event-based software like food festivals) is where I provide the value. They've never once cared what the code looks like or how it works, it's the support they are really paying for. Someone to have the answers and track them down if they don't have the answer at their fingertips, that's the value I provide (and always have if I'm being honest).
Follow-through continues to be best way to achieve success IMHO.
I will say, when working with the recent batch of frontier models, even the last batch, if you ask "Do you think we should xyz" it may sometimes push back for an alternate solution.
Now, I can't promise it's advice is worth taking, but they do seem to be taking strides at judging the relevancy of some needless additions.
I agree with your observation. Although the framing of the question signals some of the response "Do you think.. " forces the model to check for the cost-benefits.
We can definitely mould AI agents to think more critically about these things, I dont know how effective it will be in the long term honestly.
Recommend checking out Ponytail — a pi extension that behaves like a senior engineer who keeps the LLM code generation in check, and the processing of your prompts just the same
What are the actual maintenance items you will run into for offline utilities if the initial version has been throughly tested and works exactly how you want it?
Is it typically bug hunting on edge cases? Feature requests? If the initial product is polished enough, what can I realistically expect to run into down the line?
The OS changes all the time, Apple/Google stop supporting an API your app relied on, security vulnerabilities get published, even stupid stuff like timezone changes can break a perfect app in strange ways.
I am just offering a different point of view, not disagreeing with the other experiences on this thread.
I d like to think I have fully recovered from confirmed Lyme diagnosis with Doxycycline for 14 days. I had fever and weakness for a week and lowest HRV reading my Fitbit ever recorded (7ms v 50ms avg).
Interestingly, I have a lot of symptoms like anxiety, sleeplessness, and brain fog even today, but I know for a fact I had it even before Lyme. It had peaked during the COVID times when I sat at my desk working over 10 hours on the regular because there was literally nothing else to do.
So at-least in my case it seems COVID was the trigger and Lyme didn't seem to move the needle much either way.
If your data is too big for postgres, it seems like moving straight to Clickhouse is the best option. We have been through an whole array of distributed database technologies, and Clickhouse might be first one that doesn't have too many compromises.
Sai from ClickHouse here. Totally with you here, ClickHouse isn't a replacement for Postgres. Most use-cases are co-existence - Postgres for OLTP and ClickHouse for OLAP, basically right tool for the right job situation. Both are purpose-built technologies with a similar OSS ethos/story. Btw on an interesting co-incidence, Postgres turned 30 this year and ClickHouse turned 10.
Above is exactly why we are embracing the Postgres + ClickHouse stack and are investing heavily to make workflows across both these DBs very easy for developers - PeerDB for native CDC, pg_clickhouse extension for querying CH from PG, pg_stat_ch for query PG observability from ClickHouse and more such are planned for future. And recently we also announced ClickHouse Managed Postgres which pacakages this entire stack as a fully managed service https://clickhouse.com/cloud/postgres
This is a extremely common issue that happens in growing firms.
You start off with everything in Postgres, it makes the most sense.
Soon you realize some tables are growing really huge - usually some sort of time-series or log data reaching 10TB+. You can no longer fit it in one node. You can try you luck with some sharding extensions, but they add complexity to upgrades.
In that case it makes total sense to move these large tables off Postgres, and I think Clickhouse is a straight up replacement here. You can still keep your relational heavy tables in Postgres.
Yes it affects you ability to cleanly join data, and guarantee 100% consistency. With some smart application code, and schema design, you can replace parts of Postgres with Clickhouse for the big data problem.
I did this exact thing this year. I moved about >5 TB of event and log data into Clickhouse. I went from having to increase Postgres storage capacity every few months ($$$) to never thinking about it. Migrating to Clickhouse took me from constant timeouts on analytics queries to all queries returning in well under 100ms, and automated data retention using TTLs going from nightly pruning jobs that failed constantly (Postgres hates DELETEs on large tables) to again, never thinking about it. Because of this, I was able to increase retention per-account from a mere 30 days like I had -- just to keep performance and storage costs under control -- to much, much longer. Huge fan.
You can keep "columnar" data in a row based database like postgres, it's just more expensive. But with little data that's fine and reduces infrastructural complexity. When you reach too much data it gets to a point where you then actually want to use the correct database for your usecase.
It seems like a deliberate pivot towards creating an AI-era language which make GPU programming as easy as writing Python.