CognitiveLens

- for the feature the article is talking about, accepting is 'tab enter', editing is 'tab _edit/append_ enter' - it's not a lot of steps

- prompts do not always need to be detailed, and the model will still use the existing context, so you don't have to repeat anything there

- this is in Claude Code, not Claude Desktop, so typing is the central input modality - 'not typing anything at all' is an anti-goal for getting user input

I'm wondering if you might be thinking of another feature, like when it gives you a list of options with a preview, or some other application. You might also find that you can get better results with current models by leaning on existing context more and not reiterating the details - some of Anthropic and OpenAI's recent posts about their models suggests that over-specifying prompts leads to worse overall performance.

This is my thinking as well. Although the 'never do full rewrites' rule is canon for most of the software world, I have led rewrites of two large front-end applications to great success - replacing an app that 'worked' but took an order of magnitude more time to iterate on than the codebase that replaced it.

That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.

It sounds like two factors are at work - reducing personal time-tracking AND doing more AI-assisted work, both of which can reduce our ability to focus. In the case of AI, it also arguably reduces the need to focus for some kinds of productivity, so the net effect of increased output is expected.

If it helps, you can get AI to do the admin task of time tracking automatically, at least for anything that it is involved with.

The benchmark tables in the Google announcement include Opus 4.7, and the numbers are very impressive. Caveat emptor, but it's not unreasonable to compare a new Flash to a current-gen Opus, even if some of the results confirm expectations

As a project that started with a lot of idealism about how software _should_ be built, I would totally expect Bun to have an llms.txt file even if Claude wasn't using it. It's a project that is motivated in part by leading by example.

To be fair, history also demonstrates the deadly consequences of groups claiming moral absolutes that drive moral imperatives to destroy others. You can adopt moral absolutes, but they will likely conflict with someone else's.

but as mlinsey suggests, what if it's influenced in small, indirect ways by 1000 different people, kind of like the way every 'original' idea from trained professionals is? There's a spectrum, and it's inaccurate to claim that Claude's responses are comparable to adapting one individual's work for another use case - that's not how LLMs operate on open-ended tasks, although they can be instructed to do that and produce reasonable-looking output.

Programmers are not expected to add an addendum to every file listing all the books, articles, and conversations they've had that have influenced the particular code solution. LLMs are trained on far more sources that influence their code suggestions, but it seems like we actually want a higher standard of attribution because they (arguably) are incapable of original thought.

Actual Nielsen Norman Group article here https://www.nngroup.com/articles/liquid-glass/

Can mods change the linked article away from the thin blog post?

Most browsers will engage the GPU for compositing layers if they think the layers can be separated - https://www.smashingmagazine.com/2016/12/gpu-animation-doing...

I start all my UI projects with this principle, but it's extremely difficult to maintain as screens evolve. I want typography-driven interfaces with structure communicated through headings and spatial grouping, but I usually end up with far more borders and nested padding than I think is "right" as I run into the limits of whitespace as an organizing structure, particularly when the audience has a limited attention span or time to engage.

From experience, borders/cards help communicate conceptual boundaries, while whitespace helps communicate information hierarchy - Gestalt principles don't really address that distinction. For product or data-driven UI where a lot of loosely-related information/topics are shown in discrete parts of the page, cards are effective at high-level grouping. For content-driven UI, whitespace can be sufficient, and I think the article makes this clear.

Other than 'The Ultimate Developer Toolkit' (where type size is more of an issue than the card layout), I actually think the card-based version of each example layout is more compelling - easier to scan, and easier to 'chunk' - despite wanting the typography-and-whitespace alternative to be sufficient.

There are definitely projects designed with the specific intent of doing that, e.g. https://longnow.org/clock/

But there are other things, including awesome-and-dangerous nuclear waste sites, with warning messages/symbols designed to last beyond the collapse of modern civilization https://en.wikipedia.org/wiki/Long-term_nuclear_waste_warnin...

The automatic ci/cd suggestion sounds appealing, but at least in the NPM ecosystem, the depth of those dependencies would mean the top-level dependencies would constantly be incrementing. On the app developer side, it would take a lot of attention to figure when it's important to update top-level dependencies and when it's not.

I realize it's a nit-pick, but that is not at all the common definition of light pollution as it relates to night skies.

I'm skeptical that we would need determinism in a supervisor in order for it to be useful. I realize it's not exactly analogous, but the current human parallel, with senior/principal/architect-level SWEs reviewing code from less experienced devs (or even similarly-/more-experienced devs) is far from deterministic, but certainly improves quality

Think about how differently a current agent behaves when you say "here is the spec, implement a solution" vs "here is the spec, here is my solution, make refinements" - you get very different output, and I would argue that the 'check my work' approach tends to have better results.

The linked article from Steve Yegge (https://sourcegraph.com/blog/revenge-of-the-junior-developer) provides a 'solution', which he thinks is also imminent - supervisor AI agents, where you might have 100+ coding agents creating PRs, but then a layer of supervisors that are specialized on evaluating quality, and the only PRs that a human being would see would be the 'best', as determined by the supervisor agent layer.

From my experience with AI agents, this feels intuitively possible - current agents seem to be ok (thought not yet 'great') at critiquing solutions, and such supervisor agents could help keep the broader system in alignment.

You're kind of making his point - the second and third paragraphs are explicitly about the fact that he is not an Ivy League professor. Be the change you want to see in the world by doing the reading first.

To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.

I'm sure I could dig into the details, but the Solid protocol seems to have similar high-level objects to AT Protocol, but a quick search doesn't reveal many sources that refer to both - are these communities ignoring each other, competing with each other, or just too new to find common ground?

Was that kind of control well-received by your teams? Out of context, it sounds like it would be pretty rough to be an engineer on a team where your manager had sole control over what tools you could use - I suppose it might make sense for junior devs or a very small codebase, but I would caution against taking that stance in a team where you want to facilitate mutual trust

This not a criticism, but the comment you are replying to is a critique, not a criticism.

But that take is too narrow - many of the 'great' painters had extensive training in the work of previous masters, frequently copying their works repeatedly in order to develop technique and more deeply engage with what came before. After developing that base skill and understanding, they had a better toolset to express their own originality.

That is a good sign, for sure. Maybe revise to 'Facebook will eat 20% of your lunch - your business model will need to account for that'. Products like this don't have a big moat other than their network.

I'm probably too cynical, but a strong "personality and fixed opinions" doesn't really give me a lot of confidence in a human being's competency (I also wouldn't use the word "competency" to describe an AI). The person writing the prompts can absolutely bend an AI's output toward their preferences, which is a real danger.

It would be interesting to be able to have a public record of both the input and the output for stuff like this - maybe a future where we have votes for "County Prompt Engineer", and candidates get to show off the prompts that best demonstrate their ability to get 'competent' responses that have resulted in life improvements for their constituency!

At the very least, ChatGPT will admit a mistake when someone points it out. "I'm sorry for the error, you are indeed correct that corruption is unacceptable, here is my revised proposal:"

Meeting up in real life is all about network effects - people make friends through networks, organize events through networks, and discover new opportunities through networks. If you're talking about small events that you found out about through sites like Meetup, those are typically successful when you have a large-enough network of people who _might_ be interested.

I've worked in this product area before, and the big threats that we always had to watch out for were

1. Spam - once the app is large enough, you will be inundated with 'groups' that are just marketing pitches for companies and products. If you don't have a system for approving groups or figuring out how to promote high-quality over low-quality groups, you're going to struggle. Also, the whole idea of 'high-quality' vs 'low-quality' groups is dangerous in various ways.

2. All the other pitfalls of user-made content, e.g. hate speech and inappropriate content

3. People will try to use this as an online dating site - you need to decide early whether that's good or bad, but it's a huge (and potentially overwhelming) aspect of creating an app like this

4. Facebook groups will eat your lunch

5. Really great to see your early caution about building too many features and trying to be everything to everyone. All conceivable features will be requested, and you'll need to have a clear vision in order to decide what is important and what is not.

It would be interesting to know the average Roam user profile - I suspect that most don't need multiple simultaneous HD streams or the ability to transfer massive files quickly. I suspect many are RVers or people who just want to check email, make a video call that doesn't need to be high-res, and maybe browse social media.

But point taken that many users will want an upgrade option

I read the first part of your post assuming you were being sarcastic about people's expectations that every mention of AI must be about a revolutionary technical advance rather than novel applications of existing tech. But I think you're serious - the news isn't "AI has made a big advance", the news is "people are testing the idea that AI might be better at policy decisions than some humans" - and that's interesting.

There is a lot of evidence that many politicians don't have even a ChatGPT-level grasp of public policy, the legal system, or economics, but make up for it by being charming, personable, or subjectively "inspiring". It's fascinating to think about what a GPT would do with all the information that politicians have to work with, and whether that could actually result in more effective political decision making.

Yes, letting ChatGPT call the shots doesn't solve the problem of actually _getting things done_, but that doesn't trivialize the effort to elect a "human being enacting ChatGPT instructions".

As a side note, I smile at the idea that a GPT chatbot is a "simple" thing - how quickly we become inured to incredibly complex technology dressed up to be easily consumable.

I might be reading a different version of the article than you did, but the article agrees with you - URIs are a superset of URNs and URLs. I didn't see where the author says there are no URIs which are URNs - the article specifically says 'a URN is a type of URI with the scheme "urn"'

Roam is effectively the data plan, this is a new hardware dish, but I suspect it will be the preferred dish for most Roam plans.

Earthquake risk is similar to California, with very low (but not zero) risk in many places, e.g. Auckland.

The food is generally excellent in urban areas - cafe culture rules for those who can afford it.

Main issue is cost of living - housing and food costs are kind of silly relative to average income.

Mosquitos are really not an issue - people up north might have a different experience, but from Auckland on down, no one needs screens.