marwamc

much to our delight as peasants who were being lined up at the token furnaces of the big american labs.

hahaha love the spec comparison.

Also, can't wait to try this. I use a markdown-based notes/workplans/context workflow that works for the happy path but falls on its head for some edge-cases. Sometimes I have to abruptly stop a piece of work, and I might not get a chance to perform the post-work-item markdown notes ritual. If I'm resuming the same piece of work within 24hrs, it's relatively straightforward to remember what I was working on before the abrupt stop. However, sometimes it might be several days before I resume a work-item that was abruptly stopped, and in those cases, the context switchback feels like hair-pulling. This promises to reduce that pain somewhat. The last commit (usually a few steps ahead of the work-plan persistence ritual) becomes a recoverable checkpoint.

Picking a fight with the European labor unions was not a smart move in hindsight.

Backing AfD in Germany and calling them Germany's "best hope for the future" likely rubs the rest of the non-AfD polity the wrong way. He turned driving a Tesla into a political stance in Germany.

+1 for generating plans and then clearing context. I typically have a skill and an agent. I use the skill to generate an initial plan for an atomic unit of work, clear context and then use the agent to review said plan. Finally clear context and use the skill to implement the plan phase by phase, ensuring to review each phase for consistency with the next phase and the overall plan. I've had moderate success with this.

Research [1][2] shows that 70-85% of developer code search value comes from keyword-based queries. Developers usually search with exact terms they already know (function names, API calls, error messages) and less so with natural language concepts. Github's codesearch famously runs without vector search. I wasn't aware of any BM25-only codesearch tools, so I created shebe.

See releases at https://gitlab.com/rhobimd-oss/shebe/-/releases/v0.5.6-rc3 and give it a try.

I'm continually validating and asking, is this really useful? see https://github.com/rhobimd-oss/shebe/blob/main/docs/testing/...

[1] https://research.google/pubs/how-developers-search-for-code-...

[2] https://sourcegraph.com/blog/keeping-it-boring-and-relevant-...

Got around to sorting the 404. Releases now work.

https://gitlab.com/rhobimd-oss/shebe/-/releases/v0.5.6-rc2

The split globally was ~54% hybrid/electric and ~46% gas. And author wonders why Porsche doesn't want to give up 46% of their Macan customer base? Or to be charitable, author wants Porsche to make that 46% Macan customer base, choose between an ev/hybrid Macan and whatever ICE alternative is available in that segment.

I see what's happening. I never validated those build artifacts... Thanks for the catch. Will rebuild notify you here.

Will fix the links. Meanwhile here is the releases page. I develop on gitlab and mirror to github. Need to make that clear as well.

https://gitlab.com/rhobimd-oss/shebe/-/releases

BM25 has been sufficient for my needs. I typically need to refer to codebases of existing tools as referential sources (istio, envoy, oauth2-proxy, tantivy index etc) so I just clone those repos, index them and search away. Built a cli and mcp tool for this workflow.

https://github.com/rhobimd-oss/shebe

One area where BM25 particularly shines is the refactoring workflow: let's say you want to upgrade your istio installation from 1.28 to 1.29 and maybe in 1.29 the authorizationpolicy crd has a breaking change in one of it's properties. BM25 allows you to efficiently enumerate all code locations in your codebase that need to change and then you can set the cli coders off using this list. Grep and LSP can still perform this enumeration but they have shortcomings. Wrote about it here https://github.com/rhobimd-oss/shebe/blob/main/WHY_SHEBE.md#...

Turned this into a science experiment and designed a test/workflow to rename the symbol MatrixXd -> MatrixPd in eigen and the results are promising at first glance. See https://github.com/rhobimd-oss/shebe/blob/main/WHY_SHEBE.md#...

shebe asks the simple question: "where does this symbol appear as text?". For C++ codebases that heavily use templates and macros, shebe will struggle. But I'm curious how it would actually perform, so I'm currently performing a search on https://gitlab.com/libeigen/eigen. Will report the results shortly.

When using AI coding assistants to refactor symbols across large codebases (6k+ files), developers face a binary choice: precision (LSP-based tools) or efficiency (grep/ripgrep). Shebe attempts to address this trade-off by way of a good old BM25 index, which is surprisingly fast and efficient.

Agentic refactoring was such a chore I ended up building this for my refactoring workflows.

https://gitlab.com/rhobimd-oss/shebe/-/blob/main/docs/guides...

https://gitlab.com/rhobimd-oss/shebe/-/tree/main?ref_type=he...

Then in skills or CLAUDE.md I instruct claude to use this mcp tool to enumerate all files need changing/updating.

Also communal RFCs, RFPs, Roadmapping, Architecture/Design Proposals, Design Docs and/or Reviews help socialize/diffuse org standards and expectations.

I found these help ground the mentorship and discussions between junior-senior devs. And so even for the enterprising aka proactive junior devs who might start working on something in advance of plans/roadmaps, by the time they present that work for review, if the work followed org architectural and design patterns, the review and acceptance process flows smoothly.

In my juinior days I was taught: if the org doesn't have a design or architectural SOP for the thing you're doing, find a couple of respectable RFCs from the internet, pick the three you like, and implement one. It's so much easier to stand on the shoulders of giants than to try and be the giant yourself.

This was still practice at $BIG_FINANCE in the couple of years just before covid, although by that point such team reviews were reducing in importance and prominence.

Hahaha OP could be in deep trouble depending on what types of creds/data they had in that container. I had replied to a child comment but I figure best to reply to OP.

From the root container, depending on volume mounts and capabilities granted to the container, they would enumerate the host directories and find the names of common scripts and then overwrite one such script. Or to be even sneakier, they can append their malicious code to an existing script in the host filesystem. Now each time you run your script, their code piggybacks.

OTOH if I had written such a script for linux I'd be looking to grab the contents of $(hist) $(env) $(cat /etc/{group,passwd})... then enumerate /usr/bin/ /usr/local/bin/ and the XDG_{CACHE,CONFIG} dirs - some plaintext credentials are usually here. The $HOME/.{aws,docker,claude,ssh} Basically the attacker just needs to know their way around your OS. The script enumerating these directories is the 0777 script they were able to write from inside the root access container.

Another example is they would enumerate your directories and find the names of common scripts and then overwrite your script. Or to be even sneakier, they can append their malicious code to an existing script in your filesystem. Now each time you run your script, their code piggybacks.

OTH if I had written such a script for linux I'd be looking to grab the contents of $(hist) $(env) $(cat /etc/{group,passwd})... then enumerate /usr/bin/ /usr/local/bin/ and the XDG_{CACHE,CONFIG} dirs - some plaintext credentials are usually here.

The $HOME/.{aws,docker,claude,ssh}

Basically the attacker just needs to know their way around your OS. The script enumerating these directories is the 0777 script they were able to write from inside the root access container.

Which investors? Mozilla make money from search engine placement on their browser. If their browser stinks, as it will if they keep pursuing these orthogonal projects, you think google will pay $400MM per year to be the default search engine on there?

Insurance. You'll get fired if the AI is wrong.

My understanding is this: A skill is made up of SKILL.md which is what tells claude how and when to use this skill. I'm a bit of a control freak so I'll usually explicitly direct claude to "load the wireframe-skill" and then do X.

Now SKILL.md can have references to more finegrained behaviors or capabilities of our skill. My skills generally tend to have a reference/{workflows,tools,standards,testing-guide,routing,api-integration}.md. These references are what then gets "progressively loaded" into the context.

Say I asked claude to use the wireframe-skill to create profileView mockup. While creating the wireframe, claude will need to figure out what API endpoints are available/relevant for the profileView and the response types etc. It's at this point that claude reads the references/api-integration.md file from the wireframe skill.

After a while I found I didn't like the progressive loading so I usually direct claude to load all references in the skill before proceeding - this usually takes up maybe 20k to 30k tokens, but the accuracy and precision (imagined or otherwise ha!) is worth it for my use cases.

Nice. As a heavy claudecode user, I've ran into a certain form of this problem.

My problem was: for refactoring/renaming workflows Claude seems to run grep/ripgrep to enumerate occurrences of a symbol before renaming, but somehow misses some references, especially in test files or documentation. After renaming a symbol I would have failing tests, which Claude will dutifully fix, so not the worst problem. However the out-of-date documentation references slowly bite me in the neck because in future, Claude might read the outdated docs and make false assumptions or wrong decisions.

So I made an mcp tool that searches an indexed repo for all references/usages of a symbol and returns ranked results.

https://gitlab.com/rhobimd-oss/shebe/-/blob/main/docs/guides...

Also recently there a ShowHN about a tool called nia that does something similar. https://docs.trynia.ai/tools-features

I degoogled a long time ago but I can appreciate this move.

I see solutions to particular nits I had IRL e.g. the lack of semantic search in googlemaps. This is the ability to perform a "SELECT... JOIN... WHERE" from maps data to weather data to traffic data to safety/security stats etc.

So the LLM can now act as a query parser that operates on natural language: "find hotels in downtown within 45 minutes of a certain location in Santa Monica. Prefer hotels in locations that have such and such safety and walkability scores. Prioritize public transport as the primary mode of transport between the recommended hotels and the destination office."

Thanks @dang

OpenEmr and Istio. https://gitlab.com/rhobimd-oss/shebe/-/blob/main/docs/Perfor...

I've no idea what their architecture/implementation looks like, but I've built a similar tool for my own use and the improvements are dramatic to say the least.

Mine's a simple BM25 index for code keyword search (I use it alongside serena-mcp) and for some use cases the speeds and token efficiency are insane.

https://gitlab.com/rhobimd-oss/shebe#comparison-shebe-vs-alt...