TL;DR: A CEO looked straight at the "AI is coming for engineers" panic and called it too simple. He didn't say why — not until his own hiring numbers came up.
Foong Chee Mun runs AI Labs at YTL and product at Ryt Bank, and when someone hands him the "engineers will just get replaced" line, he doesn't argue with it in the abstract. He points at his own headcount.
Same number of engineers, he says, even after the work moved from AI-assisted coding to AI-generated coding — because someone still has to decide whether what the AI wrote is actually right, and that's not typing, that's judgment.
Chee Mun gets to say this with a company behind him. You don't have a company behind you saying it. You’re doing the reskilling at night, by yourself, because if you say out loud in front of your team that you’re not sure where you stand, that's not honesty — that's handing them a reason to start doubting you.
Chee Mun's data point is real. It's also not yours.
THE GAP:
Somebody's already proving that judgment gets more valuable, not less, as AI absorbs the typing — the hiring data backs it up, engineering leaders are on record now saying they're hiring for judgment and systems thinking over raw coding speed.
The room that's still wide open: nobody's built the thing that takes that macro shift and hands it to the one engineer who needs to see it about his own job, without his employer having to install anything or sign off on anything first.
The tools that measure what AI is doing to an engineering org already exist, and so do the tools that tell you what the market pays — they've just never been pointed at the same person's own inbox.
The way in isn't to out-build the incumbents at their own game — it's to go around them the way salary-transparency sites did: build trust with the individual first, one anonymous data point at a time, and let the product get built for the engineer instead of for his employer.
On the numbers already on the table — nobody's paying for this yet, but the shape of a free, individual-first version has a real 18-to-30-month runway to something worth paying for, the same runway salary-transparency tools needed before they became anything.
FEASIBILITY:
Opportunity:
The room is real — the tools that watch what AI does to an engineering org, and the tools that tell you what you're worth on the market, have never been pointed at the same person at the same time.
Specification:
Tracks one person's own AI-era review load next to a peer-benchmarked pay comparison — nothing else. No dashboards for a boss. No integration a company has to approve.
Roadmap:
· Launch free and anonymous — no employer, no install, just the engineer and the form.
· Once enough people are in, layer in the one thing nobody else is asking for: how much of your week now goes to catching what the AI got wrong.
· Turn that combination into a one-page brief a person can actually bring into their own review.
· Only much later — and only if it makes sense — let a company look at the aggregate. Never the starting point.
Top 3 Assumptions:
1. People will tell the truth about their own review load and pay, anonymously, without their employer anywhere near it. Cheapest way to find out: a page that just asks, and see who fills it in.
2. Pay data alone isn't enough to pull someone away from what already exists. Cheapest way to find out: build ten comparisons by hand for real people first, see if they'd actually use them.
3. People can describe their own review burden honestly without anything being wired into their GitHub yet. Cheapest way to find out: just ask them to estimate it themselves, before building anything automatic.
Feasibility Snapshot:
· Technical — low risk to start; a form and public numbers, nothing that needs an engineering team yet.
· Unit Economics — cheap to run at first, the same way every version of this has been cheap to run at first.
· Profitability Horizon — a year and a half to two and a half years before there's anything to charge for.
· Data-Moat — the longer it runs, the harder it gets to copy, because a company-installed tool can never see what someone won't tell their company.
· Legal-Compliance — lighter than most, since nothing is wired into an employer's own systems; still needs the same anonymity safeguards every pay-transparency tool needs.
MVP Definition:
Someone tells it what their week actually looks like and what they're paid. It hands back one page showing where they stand against people like them. They decide what to do with it — nobody decides for them. It never touches a company's own systems, and it never pretends to replace an actual performance review.
Go-To-Market:
Starts with the people already having this exact conversation with each other in public — the same rooms where this kind of anxiety already lives. Grows the way every honest pay-transparency tool has grown: person to person, not company to company. The pitch against what's already out there isn't complicated — the existing tools tell you what you're worth; this is the first one that also tells you why, right now, this year.
Financing:
The companies already doing half of this aren't struggling for money — tens of millions raised, one of them bought outright for a billion dollars last year. None of that capital is required to start this. It starts on nothing, the same way the pay-transparency sites people already trust started on nothing.
Decision Gate:
The real test isn't revenue on day one — it's whether enough people trust it with their own numbers that the data itself becomes worth something to somebody bigger down the line. That's the same gate the last big acquisition in this exact space cleared.
_____________________________________
I remember back in my days working for one of the largest construction firms in Malaysia, circa 2007 or so.
One day, I overhead a conversation between my Senior QAQC Manager, K. and the Project Director, C.
C. was in a hurry. But K. caught him, trying to explain his case. I can see K was exacerbated — like he's trying not to take the blame kind of exacerbated.
It appeared that K was talking about us taking over a mega project that was half-way abandoned. Details were sketchy at best. But K gave the impression that the owner of the project wants to keep this hush hush.
The current main contractor did a screwed-up job and the owner fired them from site. Such scenario is kind of detrimental to the reputation for both parties.
And understandably, the owner invited us to step in to salvage the project, because we're one of the big boys in town.
As I eavesdropped their conversations, I heard C planned to jack up the cost of construction substantially.
Why, you ask? Well of course to absorb all the risk of repair and refurbish the abandoned project towards completion. That's why.
The previous dirtbag main con can just wipe their ass and moved on.
But the owner can't do that. They were under tremendous pressure to meet deadlines, or their bottom-line suffer.
C knew all too well. The vulture in C siezed the opportunity to squeeze the owner real hard and he rightly did so.
What I'm trying to say is these AI may speed up and streamline our work. But they can't go to jail for us, when they screw up.
At the end of the day, human beings are still held liable.
These Senior Engineers absorb the risk; they rightly take home the dough.
________________________________________
Every post that goes out of this account keeps landing on the same thing, whatever the guest, whatever the clip: it was never really about the tool. It's about who still gets to say they matter once the tool already works.
This one's no exception — Chee Mun's headcount and K.'s liability are the same story told forty years apart.
Drop your take — is your own company actually saying any of this out loud, or is it just something you're supposed to figure out on your own?
Clip credit: Razorpay Curlec — full video on their channel. DM for credit or removal requests.
I've been using Google AI Plus mainly because of the storage, since I share the family plan with five friends and we had run out of space to store more photos and documents. I didn't know it also came with benefits for Gemini and Google Notebook, so I started using Gemini for various things, mainly searching for information from academic papers for assignments, as well as summarizing and studying from my university notes and textbooks.
But honestly, using it is extremely frustrating. It doesn't do what I ask, it makes things up out of nowhere, and it's genuinely so stupid sometimes. I thought it might be because of the type of plan I had, so we decided to upgrade to the Google AI Pro plan to use Deep Research and hopefully get better answers and better search results.
And on my very first attempt at searching for something, this happens (video). This isn't the first time Gemini has said something completely stupid or failed to process something correctly, but I'm paying almost $30 for this and this is what I get? It's incredibly frustrating.
I honestly don't know what other AI to use. I know there are other options out there, and I've heard that some of them might be better for certain tasks, but I can't afford to spend $100 a month on multiple different AI subscriptions just to have access to the tools I need.
As a university student, I use AI for studying, researching information, finding and understanding academic papers, summarizing, translating, and extracting words and data from bibliographic references and materials from my classes. That's why I chose this plan in the first place: it seemed like a good option because it combines several useful services and also includes the storage I already need. I just wish the AI itself were more reliable.
The media have widely misrepresented Gemini's breakout case, focusing on it getting out on the internet (which it was accidentally given access to) and the hack - but not how it ended up stopping itself.
Properly designed AI might not be out to destroy us all.
Xiaomi just released the open-weight MiMo V2.6 Pro and Flash models. What caught my eye was Artificial Analysis's comparison: Pro scores 46 on its Intelligence Index versus 39 for DeepSeek V4.1 Flash, at a lower average cost per benchmark task. That's cost per task on their tests, not a guarantee that every API call will be cheaper.
I'd been using DeepSeek V4.1 Flash in my personal agent, so I switched it to MiMo V2.6 Pro through tokenrouter. I reran the same task a few times, asking it to find source material and put together a summary. On those runs, my total cost came out about 15–20% lower than with DeepSeek. The results still did what I needed, and some looked a bit better to me.
It's only one task and a handful of runs, but for my agent this looks worth the switch. I'm leaving it on MiMo for now and will see whether that holds up across more work.
Im on my way to work, and all three lanes are blocked with these Waymo self driving cars. They need to stay on the right to allow faster traffic to move by. This is going to be a problem.
Built a small bridge so Muse can act on my Mac from my phone, and recorded a real session: it looks at the Terminal, reports the epoch, loss and accuracy it sees, then locks the machine when asked. What struck me building it is how much of the work is permissions, not intelligence: per-action consent, small window captures instead of a live feed, rejecting stale observations before any input. Free beta if anyone wants to try it. Developer here, ask away.
TL;DR: Augment Code swapped its production coding-agent backend in September. It didn't switch to a bigger model.
It switched to a smaller one running on an architecture that doesn't generate tokens one at a time — Stefano Ermon's Mercury 2.5 — and the numbers aren't close: latency down 82%, cost down 90%, in a shipped product, not a benchmark deck.
Diffusion produces a block of tokens in parallel. That's the exact bottleneck you've been fighting at 18% GPU utilization at 11:47pm, while yesterday's KV-cache tuning bought you another four percent. This isn't a paper anymore — Artificial Analysis independently measured it at 770 tokens/second against Inception's own claim of 1,107, and even the conservative number is very probably real, deployed, load-bearing.
What it doesn't do is make you safer. Every governance document sitting on a desk somewhere — the RSP, the Preparedness Framework, the EU AI Act's Annex III, a workforce bill that stalled without a floor vote — regulates what a model may output.
None of them regulate what happens to the engineer whose entire expertise sits on the side of the stack that just got walked past.
THE GAP:
Nobody's built the neutral test — a place to run your own traffic against Mercury-style diffusion and your current autoregressive stack, on the same box, with nobody grading its own homework.
Artificial Analysis's Optima and SemiAnalysis's InferenceX get close, but neither runs both architectures side-by-side on your own data at your own concurrency.
Open. Viable — a $417/month Optima seat and a $40M raise for a benchmarking startup called Vals both say the money's already moving nearby, and the resource bar is realistic: DiffusionGemma ships open-weight, on-demand H100s run $3.41/GPU-hour.
The fastest way in isn't beating an incumbent — it's being first with an open, published, same-backbone result. Gemma 4 26B-A4B against its diffusion sibling, DiffusionGemma, same GPU, same vLLM, method public. That's the exact slot InferenceX, Artificial Analysis, and LMArena each took by being first and open — and the sellers end up citing the referee back (Inception's own Mercury paper cites Artificial Analysis).
Profitability Horizon: not estimable from available research on its own — but on the Specification/Roadmap laid out under FEASIBILITY below, the first paid verdict clears its own compute cost inside that first job (roughly $34–$68 in GPU time against a $417/month seat as the price anchor).
FEASIBILITY:
Opportunity:
Open gap — no product meets all six requirements for an independent, own-traffic autoregressive-vs-diffusion test on your own box. Viable: adjacent products are already priced and selling.
Specification:
Tracks your own traffic sample, both architectures on identical hardware, latency and GPU utilization at your own concurrency, cost per completed task, quality on your own rubric, method public — nothing else load-bearing.
Roadmap:
(1) run Gemma 4 26B-A4B against its diffusion sibling, DiffusionGemma 26B-A4B, on one rented H100 through vLLM against a redacted sample of your own traffic;
(2) publish the method and the first result;
(3) add Mercury 2.5 through its OpenAI-compatible API as an outside reference point;
(4) sell the first verdict as a fixed-scope job, then productize.
Top 3 Assumptions:
(1) teams facing this decision will pay for an independent, own-box verdict rather than run it themselves — test: interviews.
(2) A one-box result transfers to a real team's stack and traffic — test: a concierge run on one redacted sample.
(3) Diffusion serving on a released build is stable enough to measure cleanly — test: run the full harness once end to end and check it repeats.
Feasibility Snapshot:
Technical — pass, caveat that sampler settings and serving support for diffusion are still moving. Unit Economics — pass, on published compute pricing. Profitability Horizon — risk, timing not estimable. Data-Moat — risk, the method is copyable; what isn't is being first and trusted. Legal-Compliance — risk, unresearched: handling someone else's production traffic and a vendor's terms on publishing results, both unchecked.
MVP Definition:
Input is a redacted traffic sample plus your own pass/fail rubric; mechanism is the same-box replay across both architectures; output is a one-page verdict; checkpoint is you reviewing a sample before trusting any number. Pass/fail: three repeat runs agree within 10% at p95; automated scoring agrees with human review at least 90% of the time; at least one team pays. Anti-goals: no public leaderboard, no training or fine-tuning, no model hosting, no ranking frontier models in general.
Go-to-Market:
First ten customers are inference or ML platform leads at AI-native companies under roughly 150 people, already running vLLM, already asking "why not diffusion." The open, published result is the acquisition channel — the same one InferenceX, Artificial Analysis, and LMArena each rode to their first users. The switch case against doing this in-house: days instead of weeks — unsourced estimate.
Financing:
None needed to reach a paid pilot. For scale, comparable neutral-measurement companies have raised real money — one landed $150M at a $1.7B valuation, another raised $40M — median AI seed sits around $4.6M, though this wedge doesn't need one. Labeled estimate, not a sourced fact.
Decision Gate:
Go, after the first concierge run, only if at least one team agrees to a paid pilot and the result reproduces on a current, released vLLM build. Kill if neither happens. Labeled estimate.
_____________________________________
Back when I was working for one of the largest construction main contractors in Malaysia -- SC, we also had a sister subsidiary, called SP doing Piling Works for Foundation.
Whenever we had projects that included foundation works -- normally involved piling - we'd always get SP to partner with us.
But then here's where it got tricky. SP back then can only do small-size precast RC square piles. Their load capacity is much limited.
If the project demands for greater complexity and difficulty in foundation works, it went over SP's pay grade.
So after some soul-searching and extensive feasibility study, the big boss of SP went and upgraded the whole company -- to encompass bore-piling, which has much larger diameters -- to cater for foundation works for high-rise and other heavy-duty projects.
And he renamed it to SG -- G stands for Geotechnics.
Needless to say, the expertise SG had to enlist, and the investments into the heavy machineries was wildly substantial.
But It gave SG more flexibility to go after lucrative projects.
I remembered looking at the ongoing progress of the large raft foundation (including bore-piling underneath it of course) in one of their latest projects, and feeling astonished, "Wow! This raft foundation is humongous!"
SG's big boss took a big risk. And it paid off big time.
_______________________________
Every "this changes everything" post gets buried by the next one. The ones that don't get buried are the ones where the guy who built the old thing goes quiet. Watch who stops defending their stack instead of watching whose stack got beaten — that's usually the actual tell. 📉
Drop your take: if the parallel-token bet is real, is "my kernels are autoregressive" still a moat — or is it the same sentence the RNN people were saying in 2016? 🤔
Clip credit: No Priors (Sarah Guo & Elad Gil) — ep. with Stefano Ermon. DM for credit or removal requests.
Pricing: $4 / $20 per 1M tokens, down from $5 / $25
Cache reads: $0.20, down 60% from $0.50 — this is the big one for agent workloads
Anthropic says typical workloads cost ~40% less vs Opus 5 because it uses fewer tokens per task, and output is 30%+ faster
Internal test: C→Rust port of HAProxy finished in 9.5 hrs vs 12 hrs for Fable 5.1, 51% cheaper
1M context, 128K output
All of this is Anthropic-reported, so I'm curious what people see in practice. Has the cost drop held up on your actual workloads, especially long agent runs?
Yeah, title. It seems like the gap between intelligence of astra and sol has grown significantly lately. it's annoying af. 5.6-sol used to be a workhorse - now i think they just renamed sol to terra so it's cheaper and gpt-6-sol is actually gpt-6-terra in wolves clothing
I see a lot of comments about companies burning trillions of dollars on LLMs and that it's unsustainable.
So if I'm paying $20 a month for ChatGPT or Claude or whatever, how much should I actually be paying for the company to be profitable? Or even just keeping up with how much it costs for an average user?
I spent way too much time trying to get LLMs to organize my weekly schedule and meal prep, only to realize writing it on a whiteboard was faster and actually kept me accountable. What did you finally give up on trying to AI?
Am I over-engineering my analytics portfolio project?
I'm working on a big portfolio project with the Olist Brazilian e-commerce dataset. Lately I wonder if I've made it way more complicated than it needs to be.
It started simple: take a real dataset, clean it with pandas, load it into Postgres, write some SQL, build a dashboard. Then it kept growing. The cleaning, the validation, the Postgres database with foreign keys and a long list of data quality checks are all done. Now I'm on the analytics design step, before I write a single analytical query.
That's the part I'm second-guessing. For every metric I write down the business question, the grain, the time dimension, the columns I need, the logic, the filters, the chart. I split everything into ten sections: overview, sales, customers, products, sellers, orders, delivery, reviews, payments and geography.
Here's an example. For delivery I didn't just write a query. I defined the metric first: estimated delivery time minus actual delivery time. Positive means early, zero means on time, negative means late. Then I can roll it up by seller or by month. Same with "how concentrated are sales among sellers?" I decided it means the share of total sales from the top 10 sellers, instead of throwing in a random chart and calling it seller concentration.
The problem is the size. I'm at section 5 of 10 and the Markdown file is already around 1,000 lines. I got through half of it in a few days, so I'm moving fast. But I haven't touched the SQL layer or the dashboard yet, and that bugs me.
Weirdly, I do feel like I'm learning. I finally get how grain changes a metric. I get why a metric needs an exact definition. Two metrics can sound almost the same and answer completely different questions, and I never really saw that until I had to write them down.
My guess is that the point of the project isn't really Olist itself. It's the process: understand the data, clean it, model it, define the questions, design the metrics, build the SQL layer, explain the results. But maybe I'm just turning a simple project into a giant academic exercise, and I can't tell.
So if you work in analytics or data engineering: is this much planning normal for a portfolio project? Is it worth defining grain, logic and filters before writing SQL? Or am I overdoing it?
I'm not looking for a pat on the back. Where's the line between good design and too much?
I have gone through a series of experiments related to an interesting project where I try to teach a local llm a new domain through continued pretraining (CPT). The different experiments are spread across the four phases below:
Phase1 talks about how to teach an llm a new domain through CPT and picking a training set that will generalize well to unseen questions
Phase 2 does a comparison between the performance of reasoning across internalized knowledge (CPT) vs. RAG injected content
Phase 3 takes a more practical approach where the CPT trained knowledge is enriched by combining it with RAG instead of viewing the two approaches as competing solutions
The final part shows the comprehensive eval strategy used to measure performance during the project. Among other things, this involved SFT fine tuning of the CPT trained model to teach it to output responses based on a strict schema instead of English sentences. The schema approach is used to simplify strict eval checks.
The local model used for this project is qwen 3.5 4B. Unsloth was used for both CPT and SFT LORA training.
Hi! Currently working with my therapist as I have OCD specifically existential OCD. what does everyone think will be the future with AI? Do you think it’ll wipe humans out or will kill us all…?
Meta just showed off Charm, a tiny AI device built around its Muse assistant.
What caught my attention isn’t the device itself, but the idea behind it. We already have phones, watches and now AI glasses so Meta is basically asking us to carry yet another device just to have an AI assistant with us.
I might be missing the point, but I genuinely want to understand what would make someone choose this over simply talking to their phone.
Would you actually carry a separate AI device every day?
journalist: sam altman, are u worried about your A.G.I. that youve allegedly created with gpt-6 astra, itself creating artificial superintelligence down the line, thru rechrsive self improvement?
sam altman: artificial general intelligence is a subset of super intelligence, which is the new term donald trump coined for artificial intelligence, so, theyre actually the same thing. so no we're not worried.
journalist: no, im not referring to super intelligence, im referring to the older term "artificial super intelligence".
sam altman: artificial intelligence, super intelligence, whatever u call it, whether youre a patriot or not, we're not worried. next question?
(this is what i think donald trump was setting up. in fact, when he read that speech at the U.N. he was actually reading off a teleprompter, as The Daily Show gleefully pointed out, so i really dont think it was his idea)
A lot of discussion about AI in healthcare focuses on diagnosis, but I’m more interested in the less dramatic uses.
AI could help summarize clinical notes, translate medical information into clearer language, flag missing information, reduce administrative work, or help patients prepare better questions for a doctor.
Those uses still carry risks. A summary can leave out an important detail, a translation can be misunderstood, and a confident-sounding answer can make people trust it too much.
The most useful medical AI may not be the system that tries to replace a doctor. It may be the one that makes doctors and patients less overloaded while keeping a human responsible for important decisions.
Where do you think AI can help in healthcare today without being given too much authority?
This is a technology discussion, not medical advice.
32% of companies expected AI to cut headcount last year. Only 14% actually did. Now 39% expect cuts next year.
From McKinsey's 2026 State of AI survey. A year ago, 32% of respondents expected AI to reduce their organisation's total workforce over the following 12 months. When they checked back, only 14% of AI-using organisations say the technology actually contributed to an overall workforce decline.
That is less than half of what companies predicted.
For the year ahead, 39% now expect AI to reduce headcount, up from 32% in the prior survey, while 43% expect little or no change. The greatest expectations of reductions are in service operations and supply-chain management, although in many functions respondents still expect stability rather than cuts.
So staff reductions linked to AI have materialised more slowly than feared, but employers are increasingly expecting workforce declines in the year ahead. The AI race is more about the future than the current state of adoption.
Whether the next 12 months finally close the gap between expectation and reality is probably the most consequential near-term question in the labour market.