lmao same. actually a really cool fun/concept it's definitely wordle popularity caliber, but once i got to the last 3 words and ended up in this scenario and the hint button said that i was like -_- owned.
not sure what the right game experience would be for that. a notif that says "You can still solve more words but you'll never solve them all!" doesn't quite work here, because it's sort of saying "there's only one _right_ way to win, but good luck figuring out the right order". Still, it would be better than me finding that out at the very end.
it would probably be pretty important to design levels so that the unwinnable states can't happen early in the game, but it's getting a little abstract to think about at this point. sort of brings me back to that unblock it game from the old ipod touch days.
I actually think it's less about code style and more about the disjointed way end outcomes seem to be the culmination of a lot of prompt attempts over the course of a project/implementation.
The funny thing is reviewing stuff claude has made isn't actually unfamiliar to me in the slightest. It's something I'm intimately familiar with and have been intimately familiar with for many years, long before this AI stuff blew up...
..it's what code I've reviewed/maintained/rejected looks like when a consulting company was brought on board to build something. Such a company that leverages probably underpaid and overworked laborers both overseas and US based workers on visas. The delivered documentation/code is noisy+disjointed.
> The delivered documentation/code is noisy+disjointed.
Yeah, which is what you get if your memory consists of everything you’ve read in the past 20 minutes. Most of my Claude work involves pointing it at the right things.
Like most LLM-made readme's and the six bajillion AI/agentic/llm tools now on Github I can barely get a grasp on what I'm looking at here, or how to use it practically.
> Smart code bundler that turns repositories into optimized code bundles meeting a token budget in milliseconds
Ok. So it's a tool, do I use it on my repo once? Then what? Do I use it as I go, does it sit somewhere accessible to something like Claude Code and the onus is on me to direct Claude to use this to search files instead of his out of box workflow ? I can see some CLI examples, what should I do with that where does that fit into what people are using with cursor / claude / gemini etc ?
This is the part I've been trying to hammer home about LLM created stuff. It leaves us with vague not well-understood outcomes that might do something. People are shipping/delivering things they don't even understand now and they often times can't speak to what their thing does with an acceptable level of authority. I'm not against creating tools with LLM's but I'm actually pretty against people creating the basic readme with LLM's. Wanna make a tool in an LLM? More power to you. But make sure you understand what was made, because we need humans in here telling other humans how to use it, because LLMs flat out lose the plot over the course of a large project and I think a big issue is LLM's can sometimes be more eloquent at writing than a lot of people can, so they opt for the LLM-generated readme.
But as someone who would maybe consider using something like this, I see that readme and it just looks like every claude code thing I've put together to date which is to say I've done some seemingly impossible things with Claude only to find that his ability to recap the entirety of it just ended up in a whole lot of seemingly meaningful words and phrases and sentences that actually paint a super disjointed picture of what exactly a repo is about.
This scribe tool seems to offer somewhat similar functionality to a Language Server and/or Cursor's chunked vector index.
The idea would seem to be to give instructions to your agent (Claude Code, etc) to use this tool to discover the chunks of code (not entire source files) it needs to look at to modify a particular function. You could put these instructions on how/when to use scribe someplace like .claude/rules/scribe.md
I assume this is meant to work as an override to Claude Code's normal operation where it reads entire source files into context (not sure on details as to how CC decides which files are relevant if developer hasn't explicitly told it), so if you asked CC to do something that matches the instructions you'd put in scribe.md it would run scribe, send the output (code chunks and file locations) to Claude AI, which would then base it's edit requests on that.
It's not obvious if this --covering-set command is the only one scribe currently supports, or if it has other ones to output code chunks relevant for other use cases.
Scribe grew out of fixing all the problems with code bundlers like Repomix. The covering set feature is the thing that clearly sets it apart, the performance difference is extreme; up to 98% token use reduction on SWE-bench tasks. I lead with it because it's the place where I'm far ahead of other tools, people won't adopt something because it's slightly better, scribe is a step change.
It would be useful if you had some documentation (or maybe you do?) as to how you are integrating scribe with Claude Code etc (same for Gemini CLI, or different?), and what your work flow looks like if necessary. Do you have something like scribe.md so that Claude Code is automatically invoking scribe when appropriate, or are you invoking scribe manually?
Has anyone tried scribe for larger scale projects, and green field development?
The main box on the readme should make it pretty clear. One tool call to get a covering set of a piece of code, versus wasteful grep/read/lsp/etc.
I'm not sure if you're being intentionally obtuse or you just don't have much of an attention span, but I'm not making any money off this so if you want to use 10x more tokens to get stuff done, by all means brother.
as a dude who uses all three heavily for work & personal (windows/linux/macos) macos doesnt even come close to windows in the "trying to sell me on the cloud services" front. microsoft ddos's my brain with sign in with an o365 account at every corner of computing now. microsoft products are actually insane now.
i have quite a few mac vms for development things and ive had no issue just disabling all the icloud pieces & my usage in these environments seems to be pretty damn quiet the way i like it. windows has gone completely bonkers damn file explore has network service call stacks summoning bing wtf is going on there.
feel like i have to shower after using windows now it's crazy. reminds me of early 2000s when HP laptops were just filled with bloatware when you bought them, except microsoft has now baked this unforgettable experience into their operating system.
i will remain on macos for my personal device until other hardware manufs make great hardware. i have the pleasure (or displeasure) of using lots of different devices for work so ive got a stack of thinkpads and surfaces and a couple frameworks even and apple is still leading the charge on the bonkers hardware that fits in my backpack. im loyal to no one in the end and have no dog in this fight, but i would really enjoy if someone could catch up to apples chip developments for mobile desktop computing. id love something that is as refined and performant+efficient as my m4max pro but runs linux.
all in all i think device/manuf tribalism is the lamest part of computing and it's always been in my best interests to try them all myself and switch on a whim to whatever feels like it meets my needs. im in a unique position to use a lot of diff devices and os's with what i do and there's undoubtedly frustrations with all of them. there's always going to be a free spirit inside me that champions linux to the ends of the horizons though, but apple is undeniably in a unique position to r&d bankroll tsmc, design their own soc, develop hardware and software and marry all of those things together. it's cool shit, and they'd score a lot of goodwill if they just documented their damn stuff so linux distributions could just work on these devices rather than requiring some crazy reverse engineering effort and all the associated mailing list drama that came with asahi.
I'm in violent agreement with you! Don't even know what I would have done without OCLP on my older systems, still running circles (in reliability) around other non Apple similar devices. And - for the record - I hate iPhones, as well as what Apple is doing with its OS lately.
The HP ZBook G1a is similar to a Macbook in case(*), touchpad, screen and audio quality, design and performance - just the efficiency and battery life are kind of crap and, uh, I haven't figured out yet how to configure reliable sleep on Linux. It lasts 6-7 hours idle. You can also empty the battery in an hour with heavy compile jobs, but that one Macbooks do as well according to info I've found on the net.
(*) Aluminum is more about perceived than actual quality - I wouldn't mind touching something with lower heat conduction, especially in winter. The only thing that I really like about it, compared to a Thinkpad, is the stiffness of the screen part.
ive been watching the developments of sidephone closely. ive long sought the perfect dumb-ish phone and they just dont exist, the sidephone isn't perfect either but if it delivers it could be much closer. there's pieces of it im not a fan of: closed source OS (for now) and no word on if there will at least be like SDK's to build out things for it.
the biggest leap forward in smart phones to me was personally in-hand GPS navigation. that was a game changer. I really _don't_ need to be even opening internet browsers for anything. T9 phone with a week of battery life, the ability to play some mp3's and GPS navigation and.. sigh I guess some way for me to issue MFA for okta/entraid/whatever since that's so ubiquitous with workplace security now... and I'd be set.
it's wild how advanced the likes of hardware companies were over a decade ago at making miniature hardware. the last generation ipod nano (7th I think?) was this tiny touch screen device and when I hold it in my hand today it feels ... actually magic. seriously it feels mind blowing, state of the art with how small and responsive it is. like that kind of miniaturization doesn't seem to exist anymore & it's something only the hardware giants at scale seemed to be able to do since they had supply chain connections and R&D warchests to blow on designing custom components. A lot of these dumb phones rely on generalist components I think and they aren't bankrolled with bajillions of dollars to get new R&D going and tooling online to really put an impressive device together, I just never see it in these "disconnect but stay just connected enough" dumb-phones that are trying to offer an exit from the noise of modern smart phones.
that's it, i've thought about it and i seriously don't need anything else. yeah whatsapp and spotify are super ubiquitous these days but they're literally not required to get in touch with me. and for spotify, i finally did do that whole "nerd mods an ipod 15 years later thing" and it taught me something that i needed to know about myself: ADHD + spotify = bad. my last decades playlists are a mess, i listen to music _less_ because it's just an onslaught of new stuff and access to everything. something about having a collection of music i actually took time to curate into playlists..i know what's in there i know what i can listen to. it's somewhere between meditative (which is good for me) and very intentional. acquiring new music is now also very intentional, getting it onto my device is intentional. its slower, less convenient, and somehow it makes me enjoy the music experience a lot more. im listening to more music now in a way that I haven't since I was sitting on a schoolbus next to my crush and sharing a headphone with her.
all in all I've seen a few of these "dumb phones, no distraction" device manufs now like punkt here start off with a cool design and eventually just cave and fold to some full screen touch design. to me that just nixes a lot of checkboxes for me: more screen = undoubtedly more distractions and ways to be connected, i miss buttons, i just... don't want a big phone. ever. i want to be intentional about my connectivity, and that means if i need the internet i need to just go hop on my computer. if im itching to know something and im standing in an elevator or standing on a subway, i actually don't want to be able to pull my phone out and have the immediacy of an answer. i want to stay bored in my head, work on the skill of "this is important i hope i come back to it lets index that thought and come back to it later", and just learn to live with being in my own head without the constant need to have an answer or scratch a dopamine itch immediately. there's something ive completely lost over the years, basically that ability to imagine spiderman swinging from the powerlines when i was a kid looking out the window of my parents car. whatever _that_ is, i think that came with a lot of core benefits for my brain activity that generally allowed me to have a more meaningful and happier life.
i see a lot of go hatred on HN but coming from c i actually kind of love go when i need just enough abstracted away from me to focus on doing a thing efficiently and still end up with a well-enough performing binary. i have always been obsessed with the possibility of building something that doesn't need me to install runtimes on the target i want to run it, it's just something that makes me happy. very rarely do i need to go lower than what go provides and when i do i just.. dip into c where i earned a lot of my stripes over the years.
rust is cool. a lot of really cool software im finding these days is written in rust these days & i know im missing some kind of proverbial boat here. but rusts syntax breaks my brain and makes it eject completely. it's just enough to feel like it requires paradigm shifts for me, and while others are really good at hopping between many languages it's just a massive weakness of mine. i just cant quite figure out the ergonomics of rust so that it feels comfy, my brain seems to process everything through a c-lens and this is just a flaw of mine that makes me weak in software.
golang was started by some really notable brains who had lots of time in the game and a lot of well thought out philosophies of what could be done differently and why they should do it differently coming from c. there was almost a socio-economic reason for the creation of go - provide a lang that people could easily get going in and become marketable contributors that would help their career prospects. and i think it meets that mark, i was able to get my jr engineers having fun in golang in no time at all & that's panned out to be a huge capability we added to what our team can offer.
i like the objective of rue here. reviewing the specification it actually looks like something my brain doesn't have any qualms with. but i dont know what takes a language from a proposal by one guy and amplifies it into something thats widely used with a great ecosystem. other minds joining to contribute & flesh out standard libraries, foundations backing, lots of evangelism. lots of time. i won't write any of those possibilities off right now, hopefully if it does something right here there's a bright future for it. sometimes convincing people to try a new stack is like asking them to cede their windows operating system and try out linux or mac. we've watched a lot of languages come and go, we watch a lot of languages still try to punch thru their ceilings of general acceptance. unlike some i dont really have huge tribalistic convictions of winners in software, i like having options. i think it's pretty damn neat that folks are using their experiences with other languages to come up with strong-enough opinions of how a language should look and behave and then.. going out and building it.
i do a lot of data shenanigans and it's just annoying to work with when some saas goof doesn't consider that orgs are in the business of warehousing the piss out of entire platforms worth of data that they are paying saas guys a million dollars a year for just so they can marry it together with other reporting. all roads lead to damn reporting. so if you want to woo clients but only have graphql then you should probably build some connectors they can use elsewhere they can easily retrieve all their data from. i straight up don't meet business analysts who use graphql to fetch reporting data. it's always me and my engineers sidequesting to make that data available in a warehouse env. my prob with graphql is it forces me to get intimately familiar with platforms i want to just plug into the butt of some object storage container so it can auto ingest into the warehouse and walk away. this is easy to do when the platform who knows their data and their data structure well serves up a rest api that covers all your bases. with graphql the onus is on me to figure out what the f all data i might even need and a lot of platforms have garbage documentation. so much fun since every service/app designs their db differently. no matey, postman is not the time or place for me to familiarize myself with your data model. i shall do that in the sql gladiator arena once ive ironically over fetched and beat the shit out of your graphql resolvers and stuck the data back in a database anyways.
if im developing an apps or tools to interface with some platform graphql is fine but it ends there. in situations where i need to bring data pipelines online for my org its just annoying to work with. syntactically im annoyed, my engineers are annoyed, it just amuses me to no end that platforms dont know how big reporting is at orgs they seem surprised not everyone is developing some front end app to their "modular commerce solution" and sometimes they dont even know how to answer when we ask if theres anything we should consider because we're about to hang out at the ceiling of our allowed rate limits when we bring these data pipelines online. they seem surprised that we're interested in reporting, like wtf we pay you a million a year so we can do your whatever as a service thing of fkn course we'll be reporting on the data there. how else are we gonna smoke that proverbial value add on quarterly calls?
graphql brings a query language over http. it takes a resolver that's well designed, configured and resourced. i'd rather just rawdog a sql query over the net and have postgres or whatever transpose that to json, return that and let me figure the rest out myself. ive never needed this exactness and freedom out of an api that graphql enjoyers love. i can take whatever there you throw at me and polish into the turd needed for the job, but i generally prefer vendors who have a well thought out and comprehensive and reliable set of rest endpoints. in that scenario its just easier for me to real time it into a warehouse and immediately push off to a stream or queue that populates a postgres instance if i need to build a high traffic web app. reporting needs and application needs are met and i dont have to don't need to do bespoke jujutsu sitting in a rest client and staring at json requests to determine what data i need before i architect out some one off gql query. i look at ton of data, graphql is the most overengineered and unintuitive way to review a lot of it.
its a data retrieval setup that specifically caters towards front end dev. i've done plenty of fe and i will design an app with whatever data when its needed when im building the front my headspace is completely impartial to whether or not im working with gql rest or a podunk db. so im here wondering why no one is just saying this: its nice and convenient when you're on the front, but its hardly a requirement to need a gql api. some like to think it solves for an organizational rift between front and backend devs, and that's just kicking the can down the road. im not sold on the empowerment of fe at the expensive of teams working well together. yeah isolate them more well never need to talk to fe again. great strat
since i happen to also work backend and on enterprise data i see a lot of angles that tightly scoped front end graphql enjoyers do not see and will likely never have to deal with ever. but we deal with it all the time, at least it's convenient for one of us. sucks that it isn't me
GPT:
"GraphQL is fine for frontend apps, but it’s a pain for enterprise data pipelines where the real job is bulk ingestion, warehousing, and reporting—work that REST APIs handle far more cleanly without forcing engineers to reverse-engineer undocumented schemas and babysit resolvers and rate limits. Organizations pay SaaS vendors to extract value through reporting, not to do bespoke GraphQL gymnastics, and the industry seems oddly surprised that data teams just want to ingest everything, dump it into a warehouse, and get on with their lives.
"
not sure what the right game experience would be for that. a notif that says "You can still solve more words but you'll never solve them all!" doesn't quite work here, because it's sort of saying "there's only one _right_ way to win, but good luck figuring out the right order". Still, it would be better than me finding that out at the very end.
it would probably be pretty important to design levels so that the unwinnable states can't happen early in the game, but it's getting a little abstract to think about at this point. sort of brings me back to that unblock it game from the old ipod touch days.
reply