For anyone who didn't know, caniuse lets you upload your actual usage data. Then for any capability, next to global support you also see the stats for your user-base.
Whilst I don't _really_ consider 37k LoC a day to be a particularly extreme number, my issue with all the high profile high output usage of AI, is that it doesn't really prove much of value.
I use AI in a pretty single-threaded way and my primary challenge is figuring out how to keep the LoC as minimal as possible, as well as minimise my spend. I am, unintentionally, one of the highest spenders at work; this is possible because I do more fiddly UI enhancements where the desired behaviour is often subjective and invariably hard to articulate. When I work on big backend features, my spend tends to be much lower.
What I really want from the people who have effectively unlimited tokens to spend, is to use that finding ways for the rest of us to produce higher quality output at lower costs, rather than focusing on output alone.
> Note that Rails was built as a framework for making blogs
This doesn't seem right. Yes, the "build a blog in 15 minutes" demo was pretty memorable, but I don't think it's ever really been pitched as a sweet spot for Rails. IIRC Rails was essentially extracted out of the 37Signals codebases for Basecamp et al.
I think it depends on the project, but I've found that using installable libraries becomes a bottleneck over time as you find yourself running into their limits, or trying to customise them in ways they really aren't design for.
I call it "being shot in the face with bullet points". I was trying to use an LLM to write up some guidelines on how to use a piece of tech, and I kept getting frustrated that it felt like a slide deck rather than sincere persuasion.
Maybe it's a style that's always existed in moderation, but now it feels like it's being applied to every paragraph in every document or social posting.
One thing i've struggled with with Prosemirror (via TipTap) is that I very often need to interact with JSON representation of the document programmatically to extract data from it, this means I need (okay, strongly prefer) a statically-typed representation of it.
Prosemirror doesn't really have any mechanism to do this, so i've ended up doing one of these two things:
1. Define the schema twice, once using Prosemirror and once using something like Zod. Then having a battery of equivalence tests to assert that the schemas match.
2. Build a meta schema definition layer that can output a Prosemirror schema, but conforms to the standard schema spec (https://standardschema.dev/), this approach is more viable if not using something like Tiptap.
I haven't tried using Wordgard yet, so I can't tell if it does anything to address this, but just calling it out as a pain point i'd love to see solved.
At work we've tried switching to vitest, and it's 1.5-2x slower than Jest (I think it's related to our very large and circular module graph), so performance is very much a your-mileage-may-vary thing.
If you look at the origins, the primary motivation was finding a way to get a good data loading developer experience without having to adopt Relay and GraphQL.
I remember regularly scrambling to redesign our marketing site, because the CEO was going to start speaking to investors in less than a week. So we'd always end up with a homepage that represented a new narrative the CEO was trying out, often at the expense of current customers being able to find what they were looking for (our homepage was also our primary entry point into the onboarding funnel).
I'd hazard a guess that there's a large gulf between proportion of users who know as much as you, and the total number using these tools. The fact that a message can perform wildly differently (in either cost, or behaviour if using one of the mitigations) based on whether I send it at t vs t+1 seems like a major UX issue, especially given t is very likely not exposed in the UI.
This points to a fairly fundamental mismatch between the realities of running an LLM and the expectations of users. As a user, I _expect_ the cost of resuming X hours/days later to be no different to resuming seconds or minutes later. The fact that there is a difference, means it's now being compensated for in fairly awkward ways -- none of the solutions seem good, just varying degrees of bad.
Is there a more fundamental issue of trying to tie something with such nuanced costs to an interaction model which has decades of prior expectation of every message essentially being free?
There's a _big_ continuum between disagreeing over something and an ethical hard line, it feels like a slippery slope to interpete a suggested approach for one end of that line as advocacy for applying that same approach to the other end.
In the level data, the start/goal tiles (approx 10x10 blocks of solid ground under the player and goal) and slopes aren't represented by their tile offset in the level data -- whilst all other "ground" tiles are. Instead, for slopes you're only told the start and end coordinates, and they often overlap.
So to render the slopes correctly I had to work out all the rules for which tiles were allowed next to each other, and solve some ambiguity rules -- I figured out that shallow slopes take precedence over steep ones. Eventually I cracked it, but it took quite a week or so of iteration to figure it out.
I have a few parallel AI-authored side projects on the go that have quite different shapes, and I feel quite different things about each
1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.
2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.
3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.
I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.
I did a slightly less ambitious prototype a few weeks ago where I created added lazy loading of GCS files into the just-bash file-systems, as well as lots of other on-demand files. Was a lot of fun.
just-bash comes with Python installed, so in a way that's what this has done. I've used this for some prototypes with AI tools (via bash-tool), can't really productionise it in our current setup, but it worked very well and was undeniably pretty cool.
Yeah, whilst git was more popular than mercurial, I still think mercurial would have won if bitbucket had a better UI.
It's interesting to me that the only thing that made me vastly prefer using Github over bitbucket is that Github prioritised showing the readme over showing the source tree. Such a little thing, but it made all the difference.
Ambiguity increasingly feels like the crux of estimation. By that I mean the extent to which you have a clear idea of what needs to be done before you start the work.
I do a lot of fussy UI finesse work, which on the surface are small changes, so people are tempted to give them small estimates. But they often take a while because you’re really learning what needs to be done as you’re doing it.
On the other end of the spectrum I’ve seen tickets that are very large in terms of the magnitude of the change, but very well specified and understood — so don’t actually take that long (the biggest bottleneck seems to be the need to break down the work into reviewable units).
In the LLM age, I think the ambiguity angle is going to much more apparent, as the raw size of the change becomes even less of an input into how long it takes.
I mean, the use of GraphQL for third party APIs has always been questionable wisdom. I’m about a big a GraphQL fan as it gets, but I’ve always come down on the side of being very skeptical that it’s suitable for anything beyond its primary use case — serving the needs of 1st-party UI clients.
https://caniuse.com/ciu/settings#usage