This is how I discover China has its own space station.
> When China formally requested to join the ISS program in 2007, Roscosmos and the European Space Agency (ESA) supported cooperation with China, but the Wolf Amendment, enacted by the United States since 2011, prohibited Chinese participation. That same year, China launched Tiangong-1, gaining rendezvous and docking experience.
10 years later, they had a fully operation space station. Say what you will, the Chinese are efficient once they set their mind to something.
> Say what you will, the Chinese are efficient once they set their mind to something.
Sometimes a single party communist government has its advantages. When you don't have to worry about pesky things like human rights and property rights, you can move pretty quickly!
Modern China has morphed itself into a highly capable society. They make your drones, they make your computers, they make your textiles... and mostly, they do it while providing their people better quality of life than the previous generation.
Counter-anecdotes abound as you'd expect t from a society of millions. But there's widespread prosperity over there.
There are plenty of decent opportunities for those who want to work hard, no different to how it is in the US.
While I mostly just do AI-assisted coding at work nowadays, after a long time yesterday I did some scripting in a python REPL on a remote server which didn't have any AI tooling. It felt rewarding. I was also surprised my programming muscle memory was still alive and kicking.
Just penalize the labs for rogue AI access of property like you would if a person did it. Make it difficult for them to be cavalier about running experiments.
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.
reply