HN user
I completely agree with your distinction and that is exactly what they mandated :)
I don't think that is what most people colloquially mean by "feature flags" though. Even most teams in Shopify abused "ephemeral" flags for long periods of time.
When they rolled out the mandate it was very annoying for my team because we had a lot of operational flags like you're describing that we needed to get exemptions for.
In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used.
When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times.
Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors.
In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application.
If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code.
When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point.
Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental.
The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
No other provider works like Copilot did with "premium requests". Usage limits (Codex/Claude Code), which are inherently linked to tokens, are the most common. Some providers like Amp charge you per-token like Copilot is moving to.
Microsoft's previous model was not linked to tokens at all. Complete anomaly among coding agent providers. It's not representative of token economics at large. Claude Code recently announced increased limits. Codex does regular limit refreshes.
Tokens are pretty damn abundant even though they're not bargain basement cheap yet.
Why would you extrapolate from Microsoft's very poor setup to tokens in general then if you know it's stupid and not representative?
The fact you are trying to use Copilot as an example here shows you don't understand how Copilot's previous billing worked.
Previously they used "premium requests" which would allow you to make a request to one of the more expensive models. People abused the shit out of this because a request was disconnected from tokens.
You could make one request which used tens of dollars worth of tokens, obviously not the intended usage pattern and obviously unsustainable.
Tokens for a given intelligence level are becoming much cheaper very quickly, but everyone wants to use the smartest frontier models so tokens are not dirt cheap. Even frontier models are a bit cheaper in absolute terms than they previously were, and much cheaper in terms of intelligence.
Scheduled maintenance in 2026 is insane
No point in discussing with someone who is arguing in bad faith. I already agreed that some parts of the engineering process are safety critical. If you think there is no bullshit in the process you don't have enough knowledge about the requirements imposed by e.g. building regulations.
People like to make this point, but traditional engineering has the opposite problem: insanely overwrought processes and box-checking that exists for no reason and slows everything down to a snail's pace. Yes there are safety-critical parts, but they surrounded by a ton of bullshit.
It's also absurd to think that there is no company which does genuine software "engineering". If you break ads at Google/Meta, streaming at Netflix, etc there are massive consequences. They are heavily incentivized to properly engineer their systems.
The main thing that governs whether time is spent to well-engineer something is if there is incentive to do it. In traditional engineering that incentive is the law (Getting council approval, not getting sued, etc). In software engineering that incentive is revenue.
No it was the 3 co-founders, a part-time person and 4 engineers. Now they are 3 engineers down.
He said he wanted to state it like that because he thought just saying "3 people" undersold the impact.
On his morning walk/podcast thing about the topic he said 75% of the team = 3 developers
Definitely more than 200k per head. I remember seeing a job posting for Tailwind Labs for a (design?) engineer which was 250-300k TC.
Seems like it was an insanely profitable product, but a risky business.
Material and cut/design.
Material is not just about quality, but rarity or uniqueness. For example, japanese denim can get very expensive in part because it's very low volume. For dress pants, it might be a particularly interesting fabric.
A lot of more expensive pants also have interesting designs or proportions that are very unique or hard to find elsewhere. There is a lot of cool stuff you can get for under $500 USD though, that is still pretty expensive.
Some examples around that price range:
- https://stoffa.co/collections/trousers/products/lavender-woo...
- https://www.lemaire.fr/products/twisted-belted-pants-bl760-d...
- https://www.blueowl.us/collections/pure-blue-japan/products/...
Because it's not his job. He should elevate someone else into that IC role instead of holding it for himself. The way he describes it, there is no one else in the company who can do the IC work he is doing, which is long-term bad.
Coding IC work takes a lot of focus and context that someone who is operating at the company-level should not really be in sole possession of.
To me, the whole point of these positions is to take the hit on random bullshit, planning, people management, etc and give your ICs space to do the kind of work he is taking on.
That doesn't mean you have no technical context or involvement in the development process, but it does mean you should probably be at least one step removed from it.
I wouldn't really call it "demand". It's more like one-shotting humans with a product which maximally stimulates them through what is basically a psychological hack.
We were not built with the capacity to handle the sheer amount of stimulation the modern world has. You have to put in a lot of effort to not succumb to natural desires that would have been adaptive behaviours until recent history.
The thing I'm most curious about from this article is how/why the author was demoted from E9 to E7. A demotion in itself is pretty unusual, but being bumped down 2 levels seems super weird.
E: ok watched an interview the author gave and the answer was very boring. He requested a demotion because he moved from management back to IC.
I used both English and Hangul to search. Searching for general things like food was good, but if I was trying to find a specific address it was very difficult. Sometimes it would just return completely wrong garbage. One time I was trying to meet up with someone and only realized halfway that the destination was wrong because Naver decided to take me somewhere else despite me copying the exact address in Hangul.
Maybe more about my unfamiliarity with the Korean address format than anything else tbh.
Some things about Naver I kind of miss from Apple/Google maps, but international software in general feels much more user friendly and better UX than Korean software.
They lack a lot of polish. Functionally they're mostly usable, but some interactions are janky and I found the search to be super hit or miss.
Pretty crazy improvement, seems like he's putting his money where his mouth is
On vibe coding being self-correcting, I would point to the growing number of companies mandating usage of AI and the quote "the market can stay irrational longer than you can stay solvent". Companies routinely burn millions of dollars on irrational endeavours for years. AI has been promised as an insane productivity booster.
I wouldn't expect things to calm down for a while, even if real-life results are worse. You can make excuses for underperformance of these things for a very long time, especially if the CEO or other executives are invested.
The real problem we should be discussing is, how do we convince students and apprentices to abstain from AI until they learn the ropes for real
I hate to say it but that's never going to happen :/
No it isn't. There's literally nothing about the process that forces you to skip understanding. Any such skips are purely due to the lack of will on the developer's side
This is the whole point. The marginal dev will go to the path of least resistance, which is to skip the understanding and churn out a bunch of code. That is why it's a problem.
You are effectively saying "just be a good dev, there's literally nothing about AI which is stopping you from being a good dev" which is completely correct and also missing the point.
The marginal developer is not going to put in the effort to wield AI in a skillful way. They're going to slop their way through. It is a concern for widespread AI coding, even if it's not a concern for you or your skill peers in particular.
From the title and URL I thought the substack was "Big Tech Public Relations"
__350x-ing__, not 35
I tend to agree, which makes it all the more amusing that companies brag about being so selective. It seems like largely artificial and random selectivity.
I'm pretty sure it's because an image of a banana under a microscope generated by the model went super viral
I'm confused by this post because I think Sorbet satisfies basically all the things the author wants, and my experience with Sorbet has been really good!
He is not a "courseboi". SaaStr is a legit brand that's been around for a long time focusing on the sales side of SaaS.
You have to remember this is someone who is almost certainly completely non-technical and purely vibe coding. He won't know what things like code freeze, rollbacks, production database, etc actually mean in real engineering terms and he is putting his full trust in the LLM.
Smartphones as a lower bound is crazy
Very few people want to host/organize other people.
The end goal of throwing parties shouldn’t be friendship or getting invited to other people parties, it’s building a large loose network of people you’re acquaintances/shallow friends with and becoming a super connector.
If you ONLY want to make friends or get invited to parties I think focusing on finding specific people and spending time with them 1:1 is a much better way to do that.