From my vantage point AI consumption is being lead by tech leadership moreso than actual in-the-weeds programmers themselves. HN just happens to include more folk at the intersection of leadership and individual code contributor.
The top down push for AI is in line with the age old traditions of replacing highly skilled and highly compensated trade workers with automation. The writing is on the wall if folks care to look; many just don't want to. This has happened 1000 times before and it'll keep happening in the name of "progress" in capitalist systems for as long as there are "inefficiencies" to "resolve." AI is meant as our replacement, not as an extension of our skill as it happens to align with today.
Its increasingly obvious that the next phase in the evolution of the average programmer role will be as technical requirements writers and machine generated output validators, leaving the actual implementation outsourced to the machine. Even in that new role, there is no secret sauce protecting this "programmer" from further automation. Technical product managers eventually fall to automation given enough time and money poured into the automation of translating fuzzy, under specified ideas into concrete bulleted requirements where they can simply review the listed output, make minor tweaks and hit "send" to generate the list of jira-like units of work to farm out to a fleet of agents wearing various hats (architect, programming, validator, etc.)
The above is very much in progress already, and today I'm already spending the majority of my time reviewing the output of said AI "teams", and let me tell you: it gets closer and closer to "good enough" week by week. Last year's models are horse shit in comparison to what I'm using today with agentic teams of the latest frontier models (Opus 4.6 [1m] currently, with some Sonnet.)
Maybe we're at a plateau and the limitations inherent in GenAI tech will be insurmountable before we get to 100% replacement. But it literally won't matter in the end as "good enough" always prevails over the perfect, and human devs are far from perfect already.
I have been producing software (at fang scale) for several decades now, and I've been closely monitoring GenAI systems for coding specifically. Even just a few months ago I'd get a verbose, meandering sprawl of methods and logic scattered with the actual deliverables outlined in the prompt from these systems. Sometimes even with clear disregard of the requirements laid out, or "cheating" on validation via disabling tests or writing ones that don't actually do anything useful. Today I'm getting none of that. I don't know what changed, but I somehow get automated code with good separation of concerns, following best practices and proven architectural patterns. Sure, with a bunch of juniors let loose with AI you get garbage still, but that's simply a function of poor delegation of work units. Giving the individual developer and the AI too much leeway in the scope of changes is the bug there. Division of work into small enough units is the key and always has been for the de-skilling portion of automating away skilled human labor for machines. We're just watching Marxist theory on capitalist systems play out in real time in a field generally thought to be "safe." It certainly won't be the last.
Recently one of my friends got email hijacked and whatever entity it was seemingly used her past sent emails as a training corpus to construct some very convincing pleas for donations involving a dog rescue she's been operating for several years.
It also included personal details only her closest friends and family would know. I assume this is being done at scale now. These are NOT Nigerian prince scams of yesteryear; this is something entirely different.
Yeah, that's one of the reasons calls out of the blue are mostly reserved for emergencies in my family and friend group. Texts eliminate that factor, and are more polite. A phone call represents immediacy / urgency ("this merits interrupting whatever you might be doing right now"). A text like "hey are you free for a quick call?" lets the recipient pivot from what they're doing and engage on their terms. IMHO it's more considerate.
You're about one step away from sending an email to ask if you can send a text to ask if you can make a phone call.
It's not "more considerate" - you can ignore a phone call the same you can ignore a text. It's merely asking other people to optimize for you convenience only. That's perfectly fine to ask for, but it doesn't help with making friendships easy.
Disagree with this. Sending a text saying "Can we call when you're free" is more considerate of the other persons time than a random call. It sounds like you're trying to make it sound absurd by your 'send an email to send a text', rather than focus on _why_ the text makes sense.
Thanks, yes, exactly. (I didn't respond to parent bc borderline trolling.)
FWIW, when I do make the occasional unexpected call, I make sure to start the call with "sorry to interrupt, everyone's fine, got a sec?" or similar.
Contra the other commenter's assertion, phone calls to friends and family are typically NOT as easily ignored as texts, precisely because they're not screened. Close friends and family leave themselves open to direct contact largely to account for potential emergencies. Their phone is going to ring and/or buzz, and (for at least some number of seconds) they won't know why. During which time they might reasonably fear it's terrible news. So you're starting the interaction by having interrupted and scared them. For no good reason. Failure to understand this is maybe just a sign of immaturity. Live long enough to be on the receiving end of such calls and it'll hopefully register.
texts and emails are asynchronous. If they want to email me to call me, sure. I'd find it weird, but it's just as accessible as a text.
>It's merely asking other people to optimize for you convenience only.
no, it's compromise. Maybe they're free right now. maybe they are swamped all day with work or errands. Calling out of the blue is asking people to optimize for my convenience.
100% this. Apart from my SO and scammers, no one randomly calls me. If my brother would call me out of the blue I'd assume the worst. (Also, the one random call I vividly remember getting the past years is my mom calling me to let me know my grandfather unexpectedly passed away).
It's just needlessly anxiety-inducing. Not to mention it's a major inconvenience to interrupt someone randomly for a chat.
That’s the reason I started reaching out to old friends. A friend had died and I knew no one else would tell them. One I even had to track down through email and ask for their new phone number. But now that I’m in regular contact I find calling easier and I don’t have worst-case-scenario fears anymore.
Spam phone calls have become so horrendously common here in the US (multiple a day) that I just keep my mobile on do not disturb 24/7 with exceptions for those in my core contact group. Maybe I'll miss a call or two that actually had substance, but I'd rather be slightly more isolated than constantly annoyed. Find me on various online platforms with text chat, voice or video if you really want to reach me. Or don't.
Same here. Spam calls have really picked up these last couple of years, I also get multiple per day. Here in Switzerland you need to register with your ID to get a mobile phone number, but somehow these spam callers still manage to appear to be calling from a mobile phone, which used to be a strong signal for “not spam”.
It’s gotten so bad that I completely ignore unknown numbers, except if I’m expecting a call. This has its own downsides of course.
Tragedy of the commons. :-(
Maybe call screening can help, but at least on iOS it isn’t available yet here.
Bill 936 which would have required 1:1 expressly written consent to call was struck down in the 11th circuit court of appeals right before it was set to go into effect in Jan 2025 [1].
Trump flipped the 11th circuit by making a number of judge appointments in Jan 2020 [2]. As you correctly guessed, these two things are not unrelated.
For me it's been down the last couple years, compared to a surge under the previous president. That means he's responsible, right? Or it could be I bought a house and financial institutions leak phone numbers like a colander
It cooled under Biden for me, but who am I to say. I wouldn’t be surprised if current admin stop prosecuting against the spam callers. Some times these outfits are connected to politicians. Have you seen the 3-part documentary, Telemarketers?
Did you get laid off over the year? My spams always skyrocket on a job search. Just shows you what they are really doing with your resume (despite my LinkedIn profile being 15 years old and mostly updated. It's not hard to get my resume).
Also, AI acceleration the last few years. most of the calls I do answer are clearly fake voices trying to sound real, as opposed to some TTY.
To be clear, colima isn't a fork of docker. It's just the lima VM with the docker OCI runtime + cli which is FOSS and always has been. Docker Desktop is the pile of garbage you can kinda sorta replace it with, but PodMan and PodMan Desktop is closer to a clone of Docker than Colima. Colima _is_ Docker
We all have personal AWS environments and use them as need arises at my org. Doesn't stop the fact cloudformation deployments take inordinate amounts of time for seemingly no reason. Basic shit like pushing a new ECS task takes 10+ minutes alone. Need to push an IAM policy change by itself? 5 minutes. Maybe it's the CDK, but we've only been on that a couple years, prior we used a ansible and cloudformation templates directly but it wasn't any better. This compounds with each dev and each change across multiple stacks. Not only that cloudformation easily gets "stuck" in unrecoverable states when rollback fails and you have to manually clean up to clean up drift which can easily eat your entire day. I'll note that our stacks have good separation by concerns, doesn't matter. A full deployment of a single ECS service easily takes 30 minutes. This is so wasteful it's absurd. I'd love to NOT have to use a shim like LocalStack but the alternative is what?
It’s never taken 30 minutes to pass in a new parameter value for the Docker container.
Also as far as rollbacks just use —disable-rollbacks.
The only time I’ve had CFT get stuck is using custom resources when I didn’t have proper error handling and I didn’t send the failure signal back to CFT.
Failed deployments without rollbacks still leave you in a unusable state and manual rollbacks of a failed service deployment can take as long to cleanup as the failed rollback you just disabled especially when dealing with persistent resources. That linked fargate stack is fairly bare bones in comparison to what we run in ECS and we maintain our own AMIs that are built nightly for security updates and ECR resources from docker build pipelines which need to go together in a real AWS environment to have any hope of actually working. A failure in one has cascading effects on others and cleanup is a pain. Passing a new parameter isn't a real exercise and we need a new docker build with every code change. Glad you have a minimalist setup and can get by with what? 10m deployments end to end? Sadly that's not the world I live in...
Why are you running your own AMIs for ECS instead of just using Fargate?
The build pipeline I used in CodeBuild was build the Docker container and a sidecar Nginx container.
The parameter you pass in is the new Docker container you just built.
But how would LocalStack help?
You also don’t have massive CDK apps. The Docker images are going to change much more frequently than your persistent layer. You’re not going to be bringing up and down your VPCs, database clusters etc.
Own AMIs? Simply cost. No other reason, although we're evaluating it again, so we'll see.
We actually have several "massive" CDK projects now, depending on what metric you use for determining size. Our largest CDK app has more than 60 stacks, but with a cellular architecture that's artifially inflating the numbers a bit (n unique stacks against k AWS accounts where k > n but for n > 20, < 100) Maybe the speed at which we change persistent layers (99% additive) will slow down someday, but when you maintain a large number of services (>14) with constantly changing external contracts, it probably won't; it hasn't the last 6 years, it only gets faster.
Which services weren't supported in your use case? Currently with our enterprise contract we use all the usual suspects:
AppConfig, DynamoDB, ElastiCache, Kinesis streams, RDS/Aurora with innodb engine, S3, SecretsManager, SNS, and SQS. I'm probably forgetting a few, but we haven't hit anything unsupported (yet.)
I also haven't touched any pod stuff and have no plans to. Probably just luck of the draw we didn't hit any holes or issues, but we tend not to use any esoteric features in AWS land.
The point of those pushing AI at the top is precisely to leave all human devs "behind", as it were. Anyone who thinks otherwise is not paying attention. Whether or not they succeed in their endeavors, time will tell. In either case, if their towers of money fail to deliver on the promise or not (like the last 3 AI winters I've lived through) doesn't mean we won't have a bunch of new useful tools at our disposal in the end.
I've seen rust codebases that would make you cry along with perfectly well architected applications written in both perl and php. You're just playing into common language silo stereotypes. A competent developer can author code in their language of choice whatever that may be. I'm not sure "reaching for AI" implies anything besides that some folk prefer that tool for their work. I personally don't have a tendency to reach for AI, but that doesn't somehow imply they or I are "lesser" because of it.
> You're just playing into common language silo stereotypes.
Yes, the stereotype is what I brought up on purpose.
> A competent developer can author code in their language of choice whatever that may be. I'm not sure "reaching for AI" implies anything besides that some folk prefer that tool for their work.
More relevantly, a competent developer can use AI just like one can use PHP. It buys enormous value in the short term.
> I personally don't have a tendency to reach for AI, but that doesn't somehow imply they or I are "lesser" because of it.
Yes, just like people who use PHP can make excellent programs. Nobody in this conversation implied anyone was lesser than another.
So you're saying reputations of "atrociousness" in both cases (AI users and implied poor quality producing software devs) aren't warranted? That wasn't clear in your post (at least to me.) Simply pointing out a correlation of negative stereotypes without refuting evidence just helps reinforce them.
The implication being that execs want folks who "reach for AI" to meet some arbitrary contract targets? Sounds like optimizing for the wrong things but I've seen crazier schemes.
In my opinion the end goal of those execs pushing AI is the age old goal of seizing the means of production (of software in this case) by reducing the worker to a machine. It'll likely play out in their favor honestly, as it has many times in the past.
C# is cross platform, I'd bet money that most .Net services run on Linux these days (Azure runs more Linux VMs than Windows VMs after all) This just fills the client side gap so you can unify the full stack under one language a la node etc
The top down push for AI is in line with the age old traditions of replacing highly skilled and highly compensated trade workers with automation. The writing is on the wall if folks care to look; many just don't want to. This has happened 1000 times before and it'll keep happening in the name of "progress" in capitalist systems for as long as there are "inefficiencies" to "resolve." AI is meant as our replacement, not as an extension of our skill as it happens to align with today.
Its increasingly obvious that the next phase in the evolution of the average programmer role will be as technical requirements writers and machine generated output validators, leaving the actual implementation outsourced to the machine. Even in that new role, there is no secret sauce protecting this "programmer" from further automation. Technical product managers eventually fall to automation given enough time and money poured into the automation of translating fuzzy, under specified ideas into concrete bulleted requirements where they can simply review the listed output, make minor tweaks and hit "send" to generate the list of jira-like units of work to farm out to a fleet of agents wearing various hats (architect, programming, validator, etc.)
The above is very much in progress already, and today I'm already spending the majority of my time reviewing the output of said AI "teams", and let me tell you: it gets closer and closer to "good enough" week by week. Last year's models are horse shit in comparison to what I'm using today with agentic teams of the latest frontier models (Opus 4.6 [1m] currently, with some Sonnet.)
Maybe we're at a plateau and the limitations inherent in GenAI tech will be insurmountable before we get to 100% replacement. But it literally won't matter in the end as "good enough" always prevails over the perfect, and human devs are far from perfect already.
I have been producing software (at fang scale) for several decades now, and I've been closely monitoring GenAI systems for coding specifically. Even just a few months ago I'd get a verbose, meandering sprawl of methods and logic scattered with the actual deliverables outlined in the prompt from these systems. Sometimes even with clear disregard of the requirements laid out, or "cheating" on validation via disabling tests or writing ones that don't actually do anything useful. Today I'm getting none of that. I don't know what changed, but I somehow get automated code with good separation of concerns, following best practices and proven architectural patterns. Sure, with a bunch of juniors let loose with AI you get garbage still, but that's simply a function of poor delegation of work units. Giving the individual developer and the AI too much leeway in the scope of changes is the bug there. Division of work into small enough units is the key and always has been for the de-skilling portion of automating away skilled human labor for machines. We're just watching Marxist theory on capitalist systems play out in real time in a field generally thought to be "safe." It certainly won't be the last.
reply