You would hope that you can set overall and per-integration billing caps on things rather than just "spend any money on my linked credit card" if it's meant for a "humanless" loop to be able to run stuff off.
I mean, the court case is about these platforms being addictive to kids, so if they said "accounts for users under X years have the algo and time caps delegated to their parents' account by default" it'd go along way to negate what they're being accused of.
They've already built all the tools they need around this at the moment, it's just they give them to advertisers rather than end-users.
Generally, the microservices that I've seen work well are the type of things that you could decide to "buy" in the build vs buy debate - like you say, stuff that are either "fire and forget" or stuff where you only care about a fixed output produced, not the guts of how it's done.
Anything that depends on your core business logic within the service (if customer type X, do custom process Y) is probably not going to be a clean fit for microservices as you'd think, especially with an emergent design.
On the otherhand, when Cloud Computing started to come in, I knew a bunch of sysadmins. Some were in the "it'll never take off" camp and no doubt they know it now, kicking and screaming.
But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.
Similarly with mobile dev. As a Java dev at the time that Android came along, I didn't keep abreast of it - I can always get into it later. Suddenly the job ads were "Android Dev. Must have 3 years experience".
Sometimes, even just from self-interest, it's easier to get in on the ground floor when the surface area of things to learn is smaller than it is to wait too long before checking something out.
> But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.
lol no. There's nothing actually different about managing VMs in EC2 versus managing physical servers in a datacenter. It's all the same skills, and anyone who is competent in one can pick up the other with zero adjustment.
Maybe in a greenfield environment, but this I disagree with your assessment in an enterprise setting. Have you worked with orgs that have on-prem + cloud and are migrating? It is a massive pain and regardless of whether it's easy, people and orgs don't want to do it.
But here's the thing: learning Android dev is nothing like "learning" to use an LLM.
Obviously there are tons of tools and systems building up around LLMs, and I don't intend to minimize that, but at the end of the day, an LLM is more analogous to a tool such as an IDE than a programming language. And I've never seen a job posting that dictated one must have X number of years in Y IDE; if they exist, they're rare, and it's hardly a massive hill to climb.
Sure, there's a continuum with regards to the difficulty of picking up a tool, e.g. learning a new editor is probably easier than learning, say, git. But learning git still has nothing on learning a whole tech stack.
I was very against LLM-assisted programming, but over time my position has softened, and Claude Code has become a regular part of my workflow. I've begun expanding out into the ancilary tools that interact with LLMs, and it's...not at all difficult to pick up. It's nothing like, say, learning iOS development. It's more like learning how to configure Neovim.
In fact, isn't this precisely one of the primary value propositions of LLMs -- that non-technical people can pick up these tools with ease and start doing technical work that they don't understand? If non-technical folks can pick up Claude Code, why would it be even _kind_ of difficult for a developer to?
So, I'm with the post author here: what is there to get left behind _from_?
Not quite on topic but as an engineering manager responsible for IDE development, explaining to recruiters and candidates I wanted engineers who developed IDEs, not just used them. Unfortunately, that message couldn't get through so I saw many resumes claiming, say 5 years of Eclpse experience, but I would later determine they knew nothing of the internals of an IDE.
Presumably, people now claim 3 years of machine learning experience but via ChatGPT prompting.
> On the other[ ]hand, when Cloud Computing started to come in, I knew a bunch of sysadmins. Some were in the "it'll never take off" camp and no doubt they know it now, kicking and screaming.
> But the curious early adopters were the ones best positioned to be leading the charge on "cloud migration" when the business finally pulled the trigger.
From a technological perspective, these sysadmins were right: in nearly all cases (exception: you have a low average load, but it is essential that the servers can handle huge spikes in the load), buying cloud services is much more expensive overall than using your own servers.
The reason cloud computing took of is that many managers believed much more in the marketing claims of the cloud providers than in the technological expertise of their sysadmins.
Yeah, most companies still should not be using cloud for stuff. I think a lot of people here who work for startups don't get that, because cloud makes a ton of sense if you're a new business that has a hundred other higher priorities than spending capital on infrastructure and sysadmins. But for most companies? They are better off with on prem.
Employers check your work history. You'd better be able to back up having the amount of experience they require with paid, value-delivering work at past employers, or they'll pass.
I was an engineering manager an for decades and I did first technical phone screening of a very large number of candidates. I couldn't really assess someone's design and programming skills. So I would pick a particular area they were promoting and go as deep as I could on it, both on the technology and their project experience using it. I weeded out lots of candidates, saving my engineers' interview time for more suitable candidates. And my teams were good at giving me feedback when I let someone unqualified e slip through...
I've never actually encountered one who didn't. Just like I've never been able to actually quit on Tuesday and walk into my next role on Thursday the way Hackernews told me "any halfway decent developer" should be able to do. They tend to ask about this sort of thing in interviews too and if you prove not to have the required background, you are considered weak and filtered out.
Anyways, checking happens often enough that the risk of being considered a liar and a fraud for claiming experience you don't have is high.
I'm not sure why you're downvoted, but this is the right take IMO. I hate cheating and lying in general, but in any job posting you have to separate what are the actual requirement in term of knowledge versus what can be realistically learned on the job / doing a prototype in a weekend.
Of course don't fraud by like pretending you're a statistician when you have absolutely no mathematical background, but also don't take at face value the "Must have {x} years of experience in {y} tech" requirement when you know you have the necessary work experience to have a good grasp on it in a few weekend prototypes, and you also know that the job doesn't actually require deep expertise of that particular tech.
I did the same for my first React.js job, and I didn't feel bad because 1) I was honest about it and did not sold myself as a React expert, and 2) I had 10 years of front-end development, and I understood web dev enough to not be baffled by hooks and the difference between shallow copy vs. deep copy of a data structure, so passing technical test was good enough for it.
Aside from physical real-world purchases, just opening up the space that agents get access to would be another feature. E.g. if you ask Claude to summarise a Twitter thread, it will say "I can't access, please paste the contents in here". That's fine with a human in the loop, but prevents it using Twitter as a source during deep research, say.
Similarly with paywalled sites like the New Yorker or research journals - If the LLM came back to you and said "I've found these 5 articles. Do you want me to add them as sources to summarise (access cost: $0.05)?" or you give it a budget upfront "Access whatever you think is most useful, but don't spend more than $0.10"
At the moment, sites either allow bots full access or block them, but this could provide a middle ground.
It's backed by a crypto wallet that it's using for its funds - if you decide to put $500k into the wallet that you've giving carte blanche access to an LLM, maybe you do deserve to shoulder some of the blame
> As an alternative to setting up an account and getting an API key, your agent can interact with services on demand and pay per invocation. Your agents only needs access to a crypto wallet.
Let's say I wanted to ask an agent to use Google Maps APIs to produce a look-up of all bakeries in a city, say, and then find all their mentions across platforms - e.g. Twitter, Reddit, Yelp, etc etc.
Without something like this, I'd need to manually set up accounts across multiple platforms, all with different billing/subscription cycles. Go through account set-up/validation. Then give an agent an API key with potentially unrestricted access — it might run up a huge bill, or could get my account suspended if it goes a bit haywire and starts spamming calls, say.
If vendors decided to all support the protocol, I could give an agent $10, tell it the task and let it go without any of the manual handholding but with a hardcap on what it can spend if something goes wrong.
You would hope that you can set overall and per-integration billing caps on things rather than just "spend any money on my linked credit card" if it's meant for a "humanless" loop to be able to run stuff off.
reply