My spiciest take: 🌶️ You only need prod. Other environments are optional, and may cause more problems than they solve. Imagine prod was our team’s only environment. We’d: - write lots of tests - stop batching work in lower environments - stop rushing to hit arbitrary release cutoff dates - stop spending hours every week maintaining and coordinating work in lower environments - auto-deploy upon merge - release small changes multiple times a day - monitor prod via automated checks that notify us of issues - use feature flags and phased releases to safely test in prod before making a feature visible to everyone These are mature dev team practices. Having only prod *forces* them. So, your team might be better off with only prod than with a bunch of non-prod environments.

You know why I don’t buy the “everyone will build their own software” take? I can build this. I have the tools. I know how (probably). But I don't want to. I want someone else to to build it maintain it, and charge me for it.

I have vim psychosis

it's been a year since Arc was discontinued and no browser comes close to what it is they had something so special in it and threw it away

New pet peeve: cli's that install new skills onto my system without asking.

You might believe you should spend less time thinking about code because of AI. I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability. At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time. Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change. I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance. I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.

Skills should be: - Concise - Responsible for one thing, not multi-step - Composable - Progressively disclosed - Harness-agnostic What else? Or - what did I get wrong?

It's basic common sense Ports only open for you (via Tailscale) or web traffic (via Cloudflare) Open for 8 billion people or for 2 companies What would be safer? x.com/fireleap_/status/20578…

Codex anywhere and everywhere, all the time. Now your Mac doesn’t have to be unlocked for Codex to use your computer. From your phone, Codex can securely use apps on your Mac, even when the screen is off and locked. developers.openai.com/codex/…

Grok's claude competitor is coming Grok build is only available to $300/mo SuperHeavy users at the moment. Anyone tried it? I've been very impressed at the speed/cost/quality of the latest xai models - specifically the speech and image ones.

Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10 years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it. Feeling pretty swell about this mentality with all the supply chain attacks happening.