In order to better research, I built (ironically, mostly vibe coded) a tool to run structured "self-experiments" on my own usage of AI. The idea is I've init a bunch of hypotheses I have around my own productivity/fulfillment/results with AI-assisted coding. The tool lets me establish those then run "blocks" where I test a particular strategy for a time period (default 2 weeks). So for example, I might have a "no AI" block followed by a "some AI" block followed by a "full agent all-in AI block".

The tool is there to make doing check-ins easier, basically a tiny CLI wrapper around journaling that stays out of my way. It also does some static analysis on commit frequency, code produced, etc. but I haven't fleshed out that part of it much and have been doing manual analysis at the end of blocks.

For me this kind of self-tracking has been more helpful than hearsay, since I can directly point to periods where it was working well and try to figure out why or what I was working on. It's not fool-proof, obviously, but for me the intentionality has helped me get clearer answers.

Whether those results translate beyond a single engineer isn't a question I'm interested in answering and feels like a variant of developer metrics-black-hole, but maybe we'll get more rigorous experiments in time.

The tool open source here (may be bugs, only been using it a few weeks): https://github.com/wellwright-labs/devex

I agree that it's not obvious to me how or why Tailwind should turn a profit as a business, but there are examples of other similar companies turning profits, no?

I think of Motion (formerly framer motion) for example, which is primarily an animation library: https://motion.dev/

For the second question, depends on your definition of "meaningful" I guess. I doubt the original goal was to make money. There's OSS less prolific than Tailwind that makes money. Is it unreasonable for those projects to seek ways to compensate their projects?

[1] https://wlls.dev/blog/on-tailwind

I spent 5 minutes trying to find a way to unsubscribe and couldn't. Finally, I found it buried in the plan page as one of those low-contrast ellipses on the plan card.

Instead of unsubscribing me or taking me to a form, it opened a convos with an AI chatbot with a preconfigured "unsubscribe" prompt. I have never felt more angry with a UI that I had to waste more time talking to a robot before it would render the unsubscribe button in the chat.

Why would we bring the most hated feature of automated phone calls to apps? As a frontend engineer I am horrified by these trends.

As an applicant, I often discover reasons for or against applying for a company during the application process.

As an interviewer, it's not a dealbreaker, but it definitely stands out when someone puts in the effort to write a clear, thoughtful application.

So it would depend heavily on what the "savings" are here. Where does "20+ hours" come from?

Comments URL: https://news.ycombinator.com/item?id=46305457

Points: 2

# Comments: 0

And I realized I couldn't give a concrete answer. Lots of speculation, but I realized I didn't have hardly any real data. Inspired by Adam Grant's work on "rethinking", I'm _currently_ writing a tiny CLI to run self-experiments on my own productivity, auto-checking in / observing commits/code changes.

Goal at the end is to be able to test myself across different dimensions with "no AI", "moderate AI" (e.g. searching, inline assist), and "full AI" (agents, etc). https://github.com/wellwright-labs/pulse

In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language.

I literally just copy the docs from https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking.

In the past month I've built the following, all primarily with Claude writing the Gleam parts:

- A websocket-first analytics/feature flag platform (Gleam as the backend): https://github.com/devdumpling/beacon

- A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe

- A private autobattler game backend built for the web

While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang.

EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.

As others have mentioned, would love a more thorough overview and/or a "who is this for".

Comments URL: https://news.ycombinator.com/item?id=46062805

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45927978

Points: 4

# Comments: 0

[1] https://bun.sh/docs/runtime/web-apis

You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.

Some examples:

- Inlining CSS is usually faster, but there are caveats to this. [1]

- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.

Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.

[1] https://www.slideshare.net/slideshow/performance-now-24-perf...

* related video to above slides: https://www.youtube.com/watch?v=j5E_U_hu7g0

Some critiques:

1. As others have mentioned, lots of abstract in here, not so much data. That's a hard sell to engineers. You're going to get a lot of theory responses, which maybe is what you want at this stage, but it might help to make that clearer if so.

To avoid this, you might consider refocusing the narrative. I have personally found that while appealing to Developer Experience (DX) is the fad, debating DX is an uphill battle. IMO we should appeal to something more concrete: User Experience. The discussion has to start and end with users. DX is part of it, but often over-represented. If I can sit down with someone and show them X technology is failing our users because Y fundamental flaw, the conversation is no longer on frameworkism. It's instead on how you solve problems for your users effectively. See Alex Russell's discussions on this, as divisive as they might be [1].

2. The why is clear. The what and how are not. Clarify what you're doing that is different. For example, Astro is also standards-based. Astro also approaches the problem from progressive enhancement and fundamentals over frameworkism. It seems like your focus is on separation of concerns and design principles? While I disagree on the dogmatic approach re: separation (I personally like components and composition), it would help to highlight your diff.

* I mention Astro, but this is true of other newer approaches, e.g. 11ty, Qwik, Enhance.

3. In another comment you claim that [in Nue] 90% of your codebase becomes CSS. I get that this is coming from the reduction of JS to do what HTML and CSS should, but it feels... disingenuous? At scale, no frontend or fullstack engineer I work with is spending even close to the majority of their time on CSS, regardless of stack. The focus IME is on building features, parsing/integrating data, and everything tangential to the feature (architecture review, testing, docs, etc).

Just some thoughts! I'd be interested in hearing more in the future.

[1] https://infrequently.org/2024/11/if-not-react-then-what/

1. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

2. https://docs.astro.build/en/guides/view-transitions/#built-i...

You might try "Dieter Rams inspired Apple's design philosophy."