I have had similar questions, and am still evaluating here. However, I've been increasingly frustrated with the sheer volume of anecdotal evidence from yay and naysayers of LLM-assisted coding. I have personally felt increased productivity at times with it, and frustrations at others.
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.
How does their stewardship of a CSS library exempt them from being a valid company? The fact that the market is competitive alone isn't justification.
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 your first question, IMO the purported advantage is mainly convention at scale. There's nothing inherently wrong with raw CSS in style tags or other authoring models (well, except CSS-in-JS at runtime...). Tailwind is one simple authoring model that works at scale without fuss and bikeshedding. Wrote up my experience with the advantages and disadvantages on this though a bit ago to be able to point to[1].
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?
A few days ago I was trying to unsubscribe to a service (notably an AI 3D modeling tool that I was curious about).
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.
That’s fair, and I actually agree with a lot of this. I don’t think everything should be automated, especially the parts where thinking and intent matter.
The “20+ hours” is mostly coming from the mechanical stuff: re-entering the same work history, dates, education, addresses, citizenship questions, etc. over and over across different ATSs. Not the cover letter, not the custom questions.
Ideally, the goal would be to reduce fatigue so people can put more effort into the thoughtful parts, not less.
Feels like I'm working on a million things (between work, side contracts, and creative explorations). Recently a friend asked whether AI is helping or hurting my workflow.
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
I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant).
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 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.
The project at a glance looks interesting, but it's difficult to tell what the target audience is. It doesn't help that the "About" link (which is actually a button) doesn't seem to take you anywhere.
As others have mentioned, would love a more thorough overview and/or a "who is this for".
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.
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