Dev-like

Dev-like is a tool that converts the documented engineering practices of specific organizations into skills that AI agents can use when making development decisions. Instead of having your coding agent follow generic best practices pulled from nowhere in particular, you can load a profile based on how a particular engineering team actually works. The agent then evaluates your code and proposals against that shop's real values, processes, technology choices, and decision making frameworks rather than abstract principles that may not match your context or your team's culture.

The underlying idea is that engineering culture matters. How Stripe builds software is different from how a scrappy startup builds software, which is different from how a government contractor builds software. These differences show up everywhere: code review standards, technology selection, documentation habits, testing expectations, deployment cadences, error handling patterns, and a hundred other small decisions that collectively define how a team operates. Generic coding assistants treat all these contexts the same, offering the same advice regardless of whether you are building a financial platform or a weekend side project. Dev-like tries to capture the differences and make them available as transferable context that agents can actually use.

The tool works by profiling engineering teams through publicly available sources. It pulls from GitHub repositories, documentation sites, engineering blogs, README files, and other public artifacts to build a picture of how a team operates. These findings get compiled into cited profiles with references back to the original sources, so you can verify claims rather than trusting them blindly. If a profile says a certain shop prefers composition over inheritance, it points to the blog post or style guide where that preference is documented. The profiles are stored in a searchable registry and can be loaded into agents as skills whenever you need them.

Installation works through Claude Code plugins or as a headless CLI tool. Running npx dev-like followed by a slug loads that profile into your environment. If a profile is not cached locally, the tool runs live open source intelligence to generate it, pulling public documentation and synthesizing it into a profile on the fly. The artifacts get stored in a local directory so subsequent runs do not need to regenerate them. This means you can profile organizations that are not in the registry, though effectiveness depends entirely on how much public documentation they have available. A team that blogs extensively about their engineering decisions will produce a rich profile. A team that keeps everything internal will produce a thin one.

The consent and ethics angle gets explicit attention in the documentation. The tool includes opt out procedures for organizations that do not want to be profiled, and it only uses publicly available information. This is a reasonable approach given that it is essentially scraping public engineering blogs and repos to build its profiles, but it also means the tool respects boundaries if someone asks to be excluded. The documentation makes clear that this is about learning from public examples, not about surveillance or unauthorized access to proprietary information.

Where Dev-like stands apart from generic coding assistants is the specificity. Instead of an agent that knows how to write good code in the abstract, you get one that knows how a particular team writes code. For consulting shops that work with multiple clients and need to match different house styles, this has real value. For developers who want to contribute to an open source project and match its existing conventions, loading that project's profile teaches the agent what to expect. For teams onboarding new engineers, the profile can serve as encoded institutional knowledge that helps newcomers absorb the culture faster.

Pricing is not mentioned on the site, which suggests it is either free or open source. Limitations include its reliance on public information, which means teams that do not document their practices publicly will produce thin or inaccurate profiles. The profiles also require maintenance as organizations evolve and change their practices, and the tool's value scales directly with how well the target team documents their engineering decisions. If you are profiling a shop with a sparse public footprint, expect sparse results that may not capture the full picture.