Dw, there's quite a lot of push back against AI in some of the communities I hang around in. It's just rarely seldom visible here on HN.
It's usually not about the price, but more about the fact that a few megacorps and countries "own" the ability to work this way. This leads to some very real risks that I'm pretty sure will materialize at some point in time, including but not limited to:
- Geopolitical pressure - if some ass-hat of a president hypothetically were to decide "nuh uh - we don't like Spain, they're not being nice to us!", they could forbid AI companies to deliver their services to that specific country.
- Price hikes - if you can deliver "$100 worth of value" per hour, but "$1000 worth of value" per hour with the help of AI, then provider companies could still charge up to $899 per hour of usage and it'd still make "business sense" for you to use them since you're still creating more value with them than without them.
- Reduction in quality - I believe people who were senior developers _before_ starting to use AI assisted coding are still usually capable of producing high quality output. However every single person I know who "started coding" with tools like Claude Code produce horrible horrible software, esp. from a security p.o.v. Most of them just build "internal tools" for themselves, and I highly encourage that. However others have pursued developing and selling more ambitious software...just to get bitten by the fact that it's much more to software development than getting semi-correct output from an AI agent.
- A massive workload on some open source projects. We've all heard about projects closing down their bug bounty programs, declining AI generated PRs etc.
- The loss of the joy - some people enjoy it, some people don't.
We're definitely still in the early days of AI assisted / AI driven coding, and no one really knows how it'll develop...but don't mistake the bubble that is HN for universal positivity and acclaim of AI in the coding space :).
China did users a solid and Qwen is a thing, so the scenario where Anthropic/OpenAI/Google collude and segment the market to ratchet prices in unison just isn’t possible. Amodei talking about value based pricing is a dream unless they buy legislation to outlaw competitors. Altman might have beat them to that punch with this admin, though. Most of us are operating on 10-40% margins. Usually on the low end when there aren’t legal barriers. The 80-99% margins or rent extraction rights SaaS people expect is just out of touch. The revenue the big 3 already pull in now has a lot more to do with branding and fear-mongering than product quality.
I consider myself to be an (occasional) user of AI services like the ones OpenAI and others provide. I've learned how to consume the services reasonably effectively, and make good use of them, but that's about it. I am not an AI engineer.
Similarly I know how to call cryptography libraries to get my passwords hashed using a suitable cipher before storing them. I don't understand the deep math behind why a certain cipher is secure, but that's fine. I can still make good use of cryptographic functions. I'm not a cryptography engineer either :).
My take on it is that if you should call yourself any kind of "XYZ Engineer", you should be able to understand the inner workings of XYZ.
This reading list is most likely (mostly) for those who want to get a really deep understanding and eventuellt work on contributing to the "foundational systems" (for a lack of a better word) one day.
i mostly agree w you, but theres a wide spectrum of “understand the inner workings” given rising complexity.
consider:
- does a React/frotnend engineer need to know everything about react internals to be good at their job?
- does a commercial airline pilot need to know every single subsystem in order to do their job?
- do you, a sophisticated hackernewsian, really know how your computer works?
more knowledge is always (usually) better but as a thing diffuses into practice and industry theres a natural stopping point that “technician” level people reach that is still valuable to society bc of relative talent supply and demand.
> - does a React/frotnend engineer need to know everything about react internals to be good at their job?
Yes? Well, not everything (which I define as being able to implement React from scratch). But if you want to do good work, and be able to fix those pesky bugs which result from the arcane behavior of the framework itself, then you better know your stuff.
Besides, in practice very few people understand the most basic stuff about React. Just recently I had to explain to a veteran frontend dev what list virtualization was and why it's not a good idea to display a list of 100k items directly.
I personally found that people need to understand the layer of the stack they're working on (e.g. a frontend dev should understand React). Going a layer higher or lower (or two) seems only to be handy for troubleshooting, debugging or you're simply having an expanded role.
> does a commercial airline pilot need to know every single subsystem in order to do their job?
Not a great comparison. First off, nobody is suggesting that a self-purported "AI Engineer" has to understand EVERY SINGLE SUBSYSTEM, but they should still have a strong command of the internal workings of the modern foundational material (transformers, neural networks, latent space, etc.) to style themselves as such.
The better question is "does an aviation mechanic need to understand the internal systems of an airplane?" and the answer is a resounding yes.
>- does a commercial airline pilot need to know every single subsystem in order to do their job?
Haha explain this one to the APDs (aircrew program designee, the people signing off training at airlines) please.
Every airline pilot has their horror stories of being asked how many holes are in the alternate static port of some aircraft they've flown. Or through bolts on the wheel hub, or how many plys of glass on the side cockpit window, or the formula for calculating hydroplane speed, or the formula for calculating straight line distance to the horizon from altitude of X... it just goes on endlessly.
We've used Nexus OSS just the way you describe and it worked great.
We simply set it up as a kind of "passthrough cache", so if it didn't have the package it fetched it from pypi, and stored it to be used the next time someone wanted to install the same package.
Apart from being nice to pypi, we also got a bit of a decrease in CI runtime, because it fetched packages from the local cache 99% of the time.
I'm one of the co-founders of Hotjar, so a fair bit of the original code was mine. Most of it has obviously been replaced by others after all these years.
I'm equally, if not more, proud of an extremely bad Dig Dug clone I made in Amos Pro as a kid though :). That's what eventually caused me to pursue a career in software development.
While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before.
With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.
Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.
Here are some of the things I love about Astro:
- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.
- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.
- The Astro themes (https://astro.build/themes/) are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.
This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.
Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience).
Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, it's hardly the only offender) is servers and services, and the users (other engineers) consuming those outputs can have a nice time. The DX of using Chef, though, can be ughh....
> Honestly we need more DX improvements in this industry.
Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.
100% agree with you that there's a lot of improvements to be done for a lot of the software we developers use on a daily basis. It's the term DX / Developer Experience in itself I dislike strongly. My sibling poster @swyx did a great job explaing my main gripe with using abbreviations like this.
I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)
it is subjective and overused - perfect storm for industry jargon that takes up a lot of space without saying anything more than "this thing sparks joy"
It’s no more subjective than “user experience”, which is a term thrown around far more often than “developer experience”, without complaint (and of course, the DX of Astro-using devs is UX for the Astro creators)
It might be overused, that’s an opinion, I don’t agree.
Have you used Next.js much? Next was the first (and so far, only) SSG I enjoyed using in the JS world. Just wondering if you have any comparisons. Markdown generation in Next was also a breeze.
Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform to Pulumi.
I'm actually thinking of going the other way. I've been using Pulumi for several months now, and I'm thinking of moving to Terraform, because it has a so much larger third-party ecosystem, including more providers, and tools that can analyze HCL, like Infracost and security scanners. When will I learn to see the bigger picture and value popularity over quality?
I've been part of managing rather large Terraform infrastructures (1000+ resources) for a couple of years, but I'm a Pulumi n00b with only about a month of experience.
The infrastructure I'm managing right now with Pulumi is much smaller, only around 130-140 different resources.
For me it ultimately came down to developer productivity. I'm much better at convincing Pulumi to do what I want compared to how it was with Terraform. This also makes me a much happier and less frustrated developer :).
My priorities might very well be different if I were to manage much larger infrastructures (infra cost would be more important for example).
The stack I manage with Pulumi is currently around 300 resources. (I think that count is inflated by all the secrets in AWS Secrets Manager, because each secret has two resources: the secret and the current version.) I currently manage it by myself, but I'm hoping that won't be the case for very long.
Maybe the ending of my previous comment was too cynical. But I think I've repeatedly made the mistake of valuing my productivity and happiness as a currently solo developer over what will let my company take full advantage of a big third-party ecosystem (including a large talent pool).
I don't think you're too cynical at all - I think you're exactly right! It's often much more sensible to use the "tried and true" stuff most of the time.
In my particular case I don't plan to have my company grow much at all - we're staying small. I think Pulumi is a sensible "bet" for me, because it does what I need right now really well. Sure, there's a bit of a risk, but worst case scenario I would spend a day or two to migrate what I have back to Terraform.
I would definitely not have made the call to "let's just switch everything to Pulumi" if I was still working at a larger company. As you said, a large talent pool / community is a huge deal when you have the option to hire people who can spend time learning a particular tool or language.
I work in a very large shop with lots of TF and we do not use any of the "ecosystem" other than Terragrunt. Almost all of it is experimental junk.
We use almost entirely one provider, with things like a "template" or "random" provider as well, which are really just core features they decided to split off into plugins. Even when we use SaaS that there is a provider for, we don't use the provider, because we aren't constantly changing it, or managing it doesn't require lots of people across multiple teams with multiple iterations and modules.
The title of the post is "I co-founded one of the biggest behavioural analytics companies in the world."
I have NO affiliation with Firebase at all, and I'm sorry if the poster tricked you by using an incorrect title.
I'm delighted for all potential US customers to get such a nice deal thrown their way - nice one Braintree! Too bad the offer doesn't extend to Europe, but I can appreciate the complexity in setting up something like this world wide.
I'm currently in the process of going live with two sites using Braintree, and everything has been great so far. Excellent Python API, documentation and extremely quick, knowledgeable and friendly support.
My previous payment provider experience has been with Cleverbridge, Digital River and Paymill...and so far Braintree has managed to surpass them in every single way. YMMV but for my use case Braintree has been a great fit.
It's usually not about the price, but more about the fact that a few megacorps and countries "own" the ability to work this way. This leads to some very real risks that I'm pretty sure will materialize at some point in time, including but not limited to:
- Geopolitical pressure - if some ass-hat of a president hypothetically were to decide "nuh uh - we don't like Spain, they're not being nice to us!", they could forbid AI companies to deliver their services to that specific country.
- Price hikes - if you can deliver "$100 worth of value" per hour, but "$1000 worth of value" per hour with the help of AI, then provider companies could still charge up to $899 per hour of usage and it'd still make "business sense" for you to use them since you're still creating more value with them than without them.
- Reduction in quality - I believe people who were senior developers _before_ starting to use AI assisted coding are still usually capable of producing high quality output. However every single person I know who "started coding" with tools like Claude Code produce horrible horrible software, esp. from a security p.o.v. Most of them just build "internal tools" for themselves, and I highly encourage that. However others have pursued developing and selling more ambitious software...just to get bitten by the fact that it's much more to software development than getting semi-correct output from an AI agent.
- A massive workload on some open source projects. We've all heard about projects closing down their bug bounty programs, declining AI generated PRs etc.
- The loss of the joy - some people enjoy it, some people don't.
We're definitely still in the early days of AI assisted / AI driven coding, and no one really knows how it'll develop...but don't mistake the bubble that is HN for universal positivity and acclaim of AI in the coding space :).