meet.hn/city/us-Port-Aransas
- The example in the article really is true negligence. I can't imagine that lawyer did good work even prior to using AI.
My approach is that you're responsible for anything you ship, and I don't care (within reason) how you generated it. Once it hits production, it's yours, and if it has any flaws, I don't want to hear "Well the AI just missed it or hallucinated." I don't fucking care. You shipped it, it's _your_ mistake now.
I use Claude Code constantly. It's a great tool. But you have to review the output , make necessary adjustments, and be willing to put your name on it.
- Apologies, I meant browser normalization, not polyfill. Go my terms mixed up. I also appreciate Tailwind’s pre-built sizings and quick ways to define breakpoint-base styling at the element level. That said, if you want absolute control rather than convenience, then Tailwind can be more of a hindrance than a help. I would rather not manage a lot of that myself for most of my projects.
- For real. For someone to even understand why this tool is useful and functions as intended, they need to have some deeper understanding of software development. Who cares if the implementation was done with AI. With Claude Code, I rarely write code by hand these days, yet my brain hurts more than ever from all the actual problem solving I’m able to drill into with all the programming cruft out of the way. I did it by hand for 15 years, and I don’t feel bad at all for handing that part over.
- To your first question: For me, yes. Although, If I’m going to use it in multiple places with that same style, I’d find the best way to declare it once (like in a React component). Generally I much prefer to keep the style close to the element it’s styling, and I’d rather it be done declaratively rather than native CSS with polyfills. CSS is such a core part of appearance and behavior that building and debugging structures and style together is much more effective.
- Maybe I'm just an aging cynic, but I'm waiting for the other shoe to drop when it comes to GLP-1s. There have been so many claims of positive benefits that it almost seems too good to be true. With them being so expensive, the producers have every incentive to upsell using any study they can get their hands or money on.
If it's all upside, then I'm happy to be wrong.
- I’m more interested in how people determine who they trust, and the parameters by which humans decide to trust someone.
I would wager that people are shit at determining trustworthiness based on limited information (like social media representations). In the old days before social media, you got to know people in person, and decades ago, most of the people you knew were likely people you grew up around. You knew that person’s background, how they treated people, what their family was like, and what likely influences them as a person.
So much of how we process trustworthiness is how we perceive the motives of the speaker. With shallower friendships and parasocial relationships, we want to feel connected but really lack any good context that you need to actually know who you’re listening to.
- If you are running a business with limited funding (which is most businesses), then your primary need is to seek profit in a world where profit is often never achieved at all. Otherwise, your business ceases to exist, along with your app. Sometimes that does mean emphasis on strong design, which I’d argue means delivering a great experience to your users rather than a native or non-native design choice. Other times, you’re serving a demographic that doesn’t care so much about that, and your focus is on functionality above all.
- That’s a pretty bold statement. Look at the most popular apps, and you will see across Android and iOS that the designs across platforms are more similar than they are different. We only have 2 engineers right now, but we still maintain clean native implementations for navigation, interactions, and areas where native UI excels. Neither our Android or iOS apps appear as if we just copy-pasted from one platform to the other. Both Android and iOS had been leaning into flat design for years, so it was easy to adapt the same design language for our brand across both. Not so with this return of skeuomorphic design.
- 2025 feels like a cardinal year for top-down decisions we all just have to endure for the present. The best we can do is bitch loudly and often, and hope the people at the top still feel threatened by consumers/constituents.
This Liquid Glass decision is particularly challenging for my tiny startup. We have multiple platforms including iOS and Android. I was hoping to share much of our design language across iOS and Android, but now Apple has essentially decided that this Liquid Glass will be mandatory after a year of support for "compatibility mode" that disables it for your app.
We'll now have to spend expensive engineering time to cater to Apple's design whims rather than actually working on PMF and profitability.
- Maybe if you fully hand over the reigns and go watch Youtube all day.
LLMs allow us to do large but cheap experiments that we would never attempt otherwise. That includes new architectures. Automation in the traditional sense is opposite of plasticity (because it's optimizing and crystalizing around a very specific process), but what we're doing with LLMs isn't that. Every new request can be different. Experiments are more possible, not less. We don't have to tear down years of scaffolding like old automated systems. We just nudge it in a new direction.
- This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments.
One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially having CC often one-shot a great UI for internal tools.
Being able to think at a higher level beyond grunt work and framework nuances is a game-changer for my career of 16 years.
- I adopted a couple practices (using dev containers and worktrees) just to make life a little easier. I also built my own shell script “framework” to help manage the worktrees and create project files. However, that took me just a couple days to do on my own (also using CC), and it didn’t lock me into a specific tool.
I do agree that context poisoning is a real thing to watch out for. Coincidentally, I’d noticed MCP endpoint definitions had started taking a substantial block of context for me (~20k tokens), and that’s now something I consider when adopting any MCP.
- I've found that when I work this kind of long hours for an extended period, I get far too attached to what I'm building and have a difficult time accepting that I need to change anything. Likely this happens because I've sacrificed so much to build up to the current state, and changing it would mean that I wasted time working that could have been spent with loved ones, hobbies, or just enjoying quiet.
When you work long hours on a regular basis, you begin to lose a healthy perspective on work and life.
But who knows, I’m almost 40, and I’ve been out of the target demographic for a long long time. My favorite sets were from the Space Police era.