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.

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.

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.