14 ms·

Everything as code: How we manage our company in one monorepo

227 points by benbeingbin 9mo ago

giancarlostoro 9mo ago
I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too. I guess I could work with either option now.
- emzo 9mo ago
  Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common
  - giancarlostoro 9mo ago
    Yeah, I used to hate it, but as I was building a new project I was like, oh man, I can't believe I'm even thinking of doing this, but it makes more sense LOL Instead of prompting twice, I can prompt once in one shot and it has the context of both pieces too. I guess if I ever need them to be separate I can always do that too.
  - valzam 9mo ago
    Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat
    - giancarlostoro 9mo ago
      This is where unit testing / integration testing should be implemented as guard rails in my eyes.
    - ChadNauseam 9mo ago
      Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things
      - david422 9mo ago
        > Rollout should be within a minute And if it's not, it breaks everything. This is an assumption you can't make.
      - jvuygbbkuurx 9mo ago
        You might have old clients for several hours, days or forever(mobile). This has to be taken into account, for example by aggressively forcing updates which can be annoying for users, especially if their hardware doesn't support updating.
    - aylmao 9mo ago
      This is a systems problem that can and should be fixed in the system IMO, not by relying on devs executing processes in some correct order.
    - yearolinuxdsktp 9mo ago
      Even if the rollout was atomic to the servers, you will still have old clients with cached old front ends talking to updated front ends. Depending on the importance of the changes in question, you can sometimes accept breakage or force a full UI refresh. But that should be a conscious decision. It’s better to support old clients as the same time as new clients and deprecate the old behavior and remove it over time. Likewise, if there’s a critical change where you can’t risk new front ends breaking when talking to old front ends (what if you had to rollback), you can often deploy support for new changes, and activate the UI changes in a subsequent release or with a feature flag. I think it’s better to always ask your devs to be concerned about backwards compatibility, and sometimes forwards compatibility, and to add test suites if possible to monitor for unexpected incompatible changes.
- nithril 9mo ago
  Is there any concern/issue regarding Claude’s context limit?
- deaux 9mo ago
  backend-repo $ claude --add-dir ../frontend-repo Opting for a monorepo because you don't want to alias this flag is.. something you can do, I guess.
  - odie5533 9mo ago
    What does the flag do? Just allow Claude to access that directory?
    - deaux 9mo ago
      Adds it as a working directory, yes. So pretty much the same effect that they were trying to achieve with the monorepo.
- qingcharles 9mo ago
  I changed my biggest project to a monorepo based on the same issue. I tinker with a lot of the bleeding-edge LLM tools and it was a nightmare trying to wire them all up properly so they would look at the different bits. So I refactored it into one just to make life easier for a computer.
- esafak 9mo ago
  Claude Code can actually work on multiple directories, so this is not strictly necessary! I do this when I'm working on a project whose dependencies also need to be refactored.
- joshgachnang 9mo ago
  I've been a big fan of monorepos for awhile, but like the author, not a huge fan of using e.g. yarn workspaces. React Native can get pretty pissy with hoisting. I just started putting things like implementation plans and PRDs in the repo and I'm loving it so far. It helps give AI more of the context to make good choices.
- catlifeonmars 9mo ago
  Seems like a limitation/assumption that is introduced by the tooling (Claude) and could also be improved in the tooling to work equally well with multiple repos.
- yearolinuxdsktp 9mo ago
  And think about what it’s like for humans as well—-spreading a feature over several repos with separate PRs makes either a mockery of the review process (if the PRs have to be merged in one repo to be able to test things together), or significantly increases cognitive overhead of reviewing code.
reactordev 9mo ago
I leverage git submodules and avoid the same pitfalls of monorepo scale hell we had 20 years ago. Glad it works for you though. I feel like this is the path to ARR until you need to scale engineering beyond just you and your small team. The good news here is that the author has those domains segregated out as subfolders so in the future, he/she could just pull that out into its own repo if that time came. Still adverse to the monorepo though, but I understand why it's attractive.
auslegung 9mo ago
Well written, anticipated my questions about pain points at the end except one: have you hit a point yet where deploying is a pain because it’s happening so frequently? I understand there’s good separation of concerns so a change in marketing/ won’t cause conflicts or anything to impact frontend/ but I have to imagine eventually you’ll hit that pain point. But fwiw I’m a big fan of monorepo containing multiple services, and only breaking up the monorepo when it starts to cause problems. Sounds like author is doing that
7777777phil 9mo ago
Interesting approach to giving LLMs full context. My only concern is the "no workspaces" approach; manual cd && npm install usually leads to dependency drift and "it works on my machine" issues once you start sharing logic between the API and the frontend. It’s a great setup for velocity now, but I'm curious if you've hit any friction with types or shared utils without a more formal monorepo tool?
conartist6 9mo ago
I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!
- bulbar 9mo ago
  My impression is that the world moved on from multirepo to monorepo and I vaguely remember that git submodules have some serious gotchas.
  - tedmiston 9mo ago
    https://diziet.dreamwidth.org/14666.html#what-is-wrong-with-git-submodules https://diziet.dreamwidth.org/14666.html#what-is-wrong-with-...
    - conartist6 9mo ago
      yeah, I dunno how else to say it except that if this feature worked right people would like it
- maxvirrozeito 9mo ago
  For me, integrating features that spans multiple repositories means coordinating changes, multiple PRs, switching branches on many repos to do testing. Quite time consuming. I did use submodules but I find monorepo easier to manage
  - conartist6 9mo ago
    I don't doubt that it is. Monorepo tools are much better right now. But monorepos don't compose. They don't branch. They don't scale.
eddd-ddde 9mo ago
I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.
- giancarlostoro 9mo ago
  I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and let them get their work done, they will PR when its ready.
  - eddd-ddde 9mo ago
    I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.
    - catlifeonmars 9mo ago
      What is JJ?
      - Denvercoder9 9mo ago
        https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj
  - sallveburrpi 9mo ago
    squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess
radial_symmetry 9mo ago
I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ https://nimbalyst.com/ for. We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks. Internally we have been doing a lot of what they talk about here, doing our design work, business planning, and marketing with Claude Code in our main repo.
- fragmede 9mo ago
  So the insane thing I do is I don't use worktrees. I am using multiple Claude code instances on the same project doing different things at the same time like one is editing the CSS for the login screen while another one is changing up the settings section of the project.
  - hu3 9mo ago
    yep. if the project is large enough, there are usually changes to be made that don't overlap, allowing multiple agents to work concurrently without work trees. for example I can have a prompt writing playwright tests for happy paths while another prompt is fixing a bug of duplicated rows in a table because of a missing SQL JOIN condition.
- hckr1292 9mo ago
  I’m curious about the authors experience with monorepo for marketing. I’ve found that using static site generators with nontechnical PMs resulted in dissatisfaction and more work for engineers that those PMs could handle independently in Wordpress/Contentful. As a huge believer in monorepo, I’d love to hear how folks have approached incorporating nonengingeers into the monorepo workflows.
- scottydelta 9mo ago
  > Nimbalyst is SOC-Type 2 certified What does this mean in context of downloadable desktop apps?
sethammons 9mo ago
people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of them _will not_ be able to validate and accept some upgrade. Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. Yes, this happens at slightly larger orgs. I've seen it many times. And since you have to design your changes to be backwards compatible already, why not leverage a gradual roll out? Do you update your app lock-step when AWS updates something? Or when your email service provider expands their API? No, of course not. And you don't have to lock yourself to other teams in your org for the same reason. Monorepos are hotbeds of cross contamination and reaching beyond API boundaries. Having all the context for AI in one place is hard to beat though.
- kccqzy 9mo ago
  I’m not sure why you made the logical leap from having all code stored in a single repo to updating/deploying code in lockstep. Where you put your code (the repo) can and should be decoupled from how you deploy changes. > you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes Of course you design changes to be backwards compatible. Even if you have a single node and have no networked APIs. Because what if you need to rollback? > Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. This is an organizational issue not a tech issue. Who gives that one team the power to hold back large changes that benefit the entire org? You need a competent director or lead to say no to this kind of hostage situation. You need defined policies that balance the needs of any individual team versus the entire org. You need to talk and find a mutually accepted middle ground between teams that want new features and teams that want stability and no regressions.
  - ajanuary 9mo ago
    The point is that the realities of not being able to deploy in lockstep erode away at a lot of the claimed benefits the monorepo gives you in being able to make a change everywhere at once. If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.
sails 9mo ago
I like this for adjacent things too. Company website in the same repo means you can find branding material and company tone from blogs, meaning you can generate customer slides, video demos Going further, Docs + Code, why not also store Bugs, Issues etc. I wonder
dheera 9mo ago
The thing I dislike about monorepos is that people don't ship stuff. Multiple versions of numpy and torch exist within the codebase, mitigated by bazel or some other build tool, instead of building binaries and deb packages and shipping actual products with well-documented APIs so that one team never needs to actually touch another team's code to get stuff done. The people who say polyrepos cause breakage aren't doing it right. When you depend across repos in a polyrepo setup, you should depend on specific versions of things across repos, not the git head. Also, ideally, depend on properly installed binaries, not sources.
- hckr1292 9mo ago
  That makes sense when you depend on a shared library. However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments). To be fair, this problem is not solved at all by monorepos. Basically, only careful use of gRPC (and similar technology) can help solve this… and it doesn’t really solve for application layer semantics, merely wire protocol compatibility. I’m not aware of any general comprehensive and easy solution.
  - dheera 9mo ago
    > However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments). In a polyrepo environment, either: - B updates their endpoint in a backward compatible fashion, making sure older stuff still works OR - B releases a new version of their API at /api/2.0 but keeps /api/1.0 active and working until nothing depends on it anymore, releasing deprecation messages to devs of anyone depending on 1.0
    - hckr1292 9mo ago
      Right, so all of that is independent of mono vs poly repo.
supermdguy 9mo ago
How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.
- david422 9mo ago
  I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.
  - Etheryte 9mo ago
    So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.
    - Arainach 9mo ago
      Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
      - Etheryte 9mo ago
        This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
      - hu3 9mo ago
wrs 9mo ago
This is sort of a whole product, but it’s hardly managing the whole company. Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.
- PunchyHamster 9mo ago
  Yes but AI! AI!
- webdevver 9mo ago
  i am actually eagerly waiting for someone to show the real-deal: actually everything in a github repo, including 'artfiacts', or atleast those artifacts which can't be reconstructed from the repo itself. maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO." theres a lot of power i think to have everything in one place. maybe github could add the notion of private folders? but now thats ACLs... probably pushing the tool way too far.
  - b40d-48b2-979e 9mo ago
    maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO." I don't see how this is any different from most projects where keys and the like are kept in some form of secrets manager (AWS services, GHA Secrets, Hashi Vault, etc.).
  - kittoes 9mo ago
    https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resources https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour... How close do you think this is? Deploys everything but the actual backend/frontend code.
  - maccard 9mo ago
    At a previous job we put compilers and standard libraries in version control, with custom tooling to pull the right version for what you need. We used p4 rather than git though.
doublet00th 9mo ago
I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea. Here were the downsides we ran into - Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service. - CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything") - Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time. That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released. [1]: https://pangea.cloud/ https://pangea.cloud/
- hckr1292 9mo ago
  Did you use turbo, buck or Bazel? Without monorepo tooling (and the blood, sweat, and tears it takes to hone them for your use cases), you start hitting all kinds of scaling limits in CI.
  - doublet00th 9mo ago
    We had python scripts that generated GitLab CI/CD yaml [1]. Tooting my own horn here, but it was super cool to ship fairly fast for the first year or so. By the end, we had something like 5 MB of yaml, but in order for the GitLab SaaS backend to process it, it took something like 32 gigs of ram on their MergeRequestProcessor SideKiq worker. They had to open a whole epic in order to reduce the memory usage, but I think all that work just let us continue to use GitLab as the number of services we grew increased. They recommended we use something called parent/child pipelines, but it would have been a fairly large rewrite of our logic. [1]: https://docs.gitlab.com/ci/yaml/ https://docs.gitlab.com/ci/yaml/
codegeek 9mo ago
I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?
- NERD_ALERT 9mo ago
  Hosting a developer environment remotely that you SSH into is very common. That’s how you would approach working with a monorepo that has any serious size to it.
- Carrok 9mo ago
  This is probably different between startups and enterprises. My background is purely startups, and I can't imagine not having access to 100% of the code for the company I work.
- NeutralWanted 9mo ago
  I work at Google, and yes. We use a monorepo for absolutely everything you can think of. But good luck getting that code off a corp device without being caught!
  - fragmede 9mo ago
    Android never fully made it into google3. Google is big and does so much stuff and almost everything is in there but there are exceptions!
- tn1 9mo ago
  While not talked about on HN as much, the big corps doing monorepo use something like Perforce which has "protects" tables allowing very granular access control
codingdave 9mo ago
> When you ask Claude to "update the pricing page to reflect the new limits," it can... wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?
- ra_men 9mo ago
  AI is turning in to an addiction and crutch for some people.
- cadamsdotcom 9mo ago
  Code review still exists, you know. AI didn’t magically uninvent “let’s have someone else check this over before it’s shipped”.
c-fe 9mo ago
I like this a lot. Every time I am forced to open Notion or Slite, I just wish so much it would just be .md files in a git repository.
hrdwdmrbl 9mo ago
I love the idea. It's bold. But, I hate it from an information architecture perspective. This is something that is, of course, super relevant given context management for agentic AI. So there's great appeal in doing this. And today, it might even be the best decision. But this really feels like an alpha version of something that will have much better tooling in the near-future. JSON and Markdown are beautiful simple information containers, but they aren't friendly for humans as compared with something like Notion or Excel. Again I'll say, I'm confident that in the near-future we'll start to see solutions emerge that structure documentation that is friendly to both AIs and humans.
williamtrask 9mo ago
"Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything. When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings? The monorepo isn't a constraint. It's a force multiplier." Thank you Claude :)
- esafak 9mo ago
  It wrote the code, so it's best placed to write the copy too.
  - NewsaHackO 9mo ago
    That is exactly right!
johnfn 9mo ago
This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.
- ralfhn 9mo ago
  You’d think people would at least spend 2 minutes changing obvious tells like “Why This Matters”…
- nlh 9mo ago
  It's weird it looks like only a small % of comments on here have caught on to the obvious LLM-ness of it all (I missed it the first go-around but on second read, you're is absolutely correct). I'm wondering once the exceedingly obvious LLM style creeps more and more into the public mind if we're going to look back at these blog posts and just cringe at how blatant they were in retrospect. The models are going to improve (and people will catch on that you can't just use vanilla output from the models as blog posts without some actual editing) and these posts will just stand out like some very sore thumbs. (ps all of the above 100% human written ;)
- ra_men 9mo ago
  It feels like intellectual dishonesty when it's not declared at the top of the article. I have no issues with AI, when the authors are honest about their usage. But if you stamp your name to an article without clear mention that LLMs wrote at least a significant piece of it, it feels dishonest and I disconnect from it.
stego-tech 9mo ago
Honestly, from the enterprise IT perspective? Fuck yes I love this attitude to transparency and code-based organization. This is the kind of stuff that gets me going in the morning for work, the kind of organization and utility I honestly aspire to implement someday. As many commenters rightly point out, this doesn't run the human side of the company. It could, though, if the company took this approach seriously enough. My personal two cents, it could be done as a separate monorepo, provided the company and its staff remain disciplined in its execution and maintenance. It'd be far easier to have a CSV dictate employees and RBAC rather than bootstrapping Active Directory and fussing with its integrations/tentacles. Putting department processes into open documentation removes obfuscation and a significant degree of process politics, enabling more staff to engage in self-service rather than figuring out who wields the power to do a thing. I really love everything about this, and I'd like to see more of it, AI or not. Less obfuscation and more transparency is how you increase velocity in any organization.
jensenbox 9mo ago
Oddly enough, I wrote an article about this very topic recently: https://medium.com/@jensenbox/why-monorepos-are-winning-in-the-age-of-services-and-ai-1210d0a184ed https://medium.com/@jensenbox/why-monorepos-are-winning-in-t...
graphememes 9mo ago
You can still have all the context in one place, just clone the repos to one folder on your machine, problem solved.
- shepherdjerred 9mo ago
  That introduces the problem of coordinating changes between repositories
Escapade5160 9mo ago
This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.
- talos 9mo ago
  Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.
  - lawrjone 9mo ago
    I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around. Not to say this post isn't AI generated but you might want a better tool (if one exists)
    - talos 9mo ago
      Hmm I'm curious which blog post tripped it? I tried a few from your site in 2023 and none of them were flagged as AI generated.
    - talos 9mo ago
      Yeah, it's got a real issue with false positives. And I've tried a bunch of other tools (Sapling, ZeroGPT, a few others) and actually GPTZero was the best of the bunch. The others would miss obviously AI generated content that I'd just generated to test them. I've had a blog post kicking around about this for a while, it's CRAZY how much more expensive AI detection is than AI generation. In my mind content generated today with AI "tells" like the above and a general zero-calorie-feel that also trip an AI detector are very likely AI generated.
  - teekert 9mo ago
    Pff the mental list of what I can’t use when I write is getting pretty big. Em dashes are done for, as are deep dives, delving, anything too enthusiastic, and Oxford commas… A text either has value to you or it doesn’t. I don’t really understand what the level of AI involvement has to do with it. A human can produce slop, an AI can produce an insightful piece. I rely mostly on HN to tell them apart value-wise.
root_axis 9mo ago
55 business logic services? Sounds extremely overengineered. I'm sure at least half of those services should be consolidated into others.
- senbrow 9mo ago
  There is no universally "correct" granularity. You could easily scoff the same way about some number of API endpoints, class methods, config options, etc, and it still wouldn't be meaningful without context. It's ok to split or lump as the team sees fit.
  - root_axis 9mo ago
    > There is no universally "correct" granularity. There may not be a universally correct granularity, but that doesn't mean clearly incorrect ones don't exist. 50+ services is almost always too many, except for orgs with hundreds or thousands of engineers.
harel 9mo ago
For the purpose of AI Tools, you can also have one workspace, or one directory where multiple repos are cloned to as a parent. Just saying...
bilbo-b-baggins 9mo ago
Good Christ. Imagine having decided that your price structures should be a JSON file instead of persisted in a database and then thinking that any decision made by that person/team is a good idea. I look forward to when we see the article about breaking the monorepo nightmare.
- ForHackernews 9mo ago
  Depending on how often you need to change your pricing and how many products you offer, flat files might make a lot of sense.
- wrs 9mo ago
  Sometimes this sort of thing is not a bad idea. If it's a simple data structure that doesn't change very often, you get an admin interface (vi), change tracking, and audit trail for free. Just think of it as configuration rather than data and most folks would think it's normal to do this.
burgerone 9mo ago
Had me interested up until the word "AI"
sandeepkd 9mo ago
I envy this confidence, the less you know the more confident you are.
darepublic 9mo ago
The opening blurb about updating a JSON file and seeing it reflected right away in the live web app just reminds me of a CMS.
throw-12-16 9mo ago
Sounds like a pain in the ass for non developers to contribute. Also, are we just upvoting obvious AI gen marketing slop now?
deleted 9mo ago
[deleted]
ozozozd 9mo ago
I’m not sure how seemingly most of us forgot about the context window being a finite _window_. “It’s all there Claude just read it.” Ok…
suralind 9mo ago
What’s the value proposition? I mean the fact that you have - frontend - backend - website is already confusing to me. I understand that one commit seems nice, but you could have achieve this with e.g. 3 repos and very easily maintain all of them. There’s a bit of overhead of course, but having some experience working with a team that has a few „monorepos” I know that the cost to actually make it work is significant.

227 points by benbeingbin 9mo ago

I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too. I guess I could work with either option now.

emzo 9mo ago
Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common
- giancarlostoro 9mo ago
  Yeah, I used to hate it, but as I was building a new project I was like, oh man, I can't believe I'm even thinking of doing this, but it makes more sense LOL Instead of prompting twice, I can prompt once in one shot and it has the context of both pieces too. I guess if I ever need them to be separate I can always do that too.
- valzam 9mo ago
  Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat
  - giancarlostoro 9mo ago
    This is where unit testing / integration testing should be implemented as guard rails in my eyes.
  - ChadNauseam 9mo ago
    Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things
    - david422 9mo ago
      > Rollout should be within a minute And if it's not, it breaks everything. This is an assumption you can't make.
    - jvuygbbkuurx 9mo ago
      You might have old clients for several hours, days or forever(mobile). This has to be taken into account, for example by aggressively forcing updates which can be annoying for users, especially if their hardware doesn't support updating.
  - aylmao 9mo ago
    This is a systems problem that can and should be fixed in the system IMO, not by relying on devs executing processes in some correct order.
  - yearolinuxdsktp 9mo ago
    Even if the rollout was atomic to the servers, you will still have old clients with cached old front ends talking to updated front ends. Depending on the importance of the changes in question, you can sometimes accept breakage or force a full UI refresh. But that should be a conscious decision. It’s better to support old clients as the same time as new clients and deprecate the old behavior and remove it over time. Likewise, if there’s a critical change where you can’t risk new front ends breaking when talking to old front ends (what if you had to rollback), you can often deploy support for new changes, and activate the UI changes in a subsequent release or with a feature flag. I think it’s better to always ask your devs to be concerned about backwards compatibility, and sometimes forwards compatibility, and to add test suites if possible to monitor for unexpected incompatible changes.
nithril 9mo ago
Is there any concern/issue regarding Claude’s context limit?
deaux 9mo ago
backend-repo $ claude --add-dir ../frontend-repo Opting for a monorepo because you don't want to alias this flag is.. something you can do, I guess.
- odie5533 9mo ago
  What does the flag do? Just allow Claude to access that directory?
  - deaux 9mo ago
    Adds it as a working directory, yes. So pretty much the same effect that they were trying to achieve with the monorepo.
qingcharles 9mo ago
I changed my biggest project to a monorepo based on the same issue. I tinker with a lot of the bleeding-edge LLM tools and it was a nightmare trying to wire them all up properly so they would look at the different bits. So I refactored it into one just to make life easier for a computer.
esafak 9mo ago
Claude Code can actually work on multiple directories, so this is not strictly necessary! I do this when I'm working on a project whose dependencies also need to be refactored.
joshgachnang 9mo ago
I've been a big fan of monorepos for awhile, but like the author, not a huge fan of using e.g. yarn workspaces. React Native can get pretty pissy with hoisting. I just started putting things like implementation plans and PRDs in the repo and I'm loving it so far. It helps give AI more of the context to make good choices.
catlifeonmars 9mo ago
Seems like a limitation/assumption that is introduced by the tooling (Claude) and could also be improved in the tooling to work equally well with multiple repos.
yearolinuxdsktp 9mo ago
And think about what it’s like for humans as well—-spreading a feature over several repos with separate PRs makes either a mockery of the review process (if the PRs have to be merged in one repo to be able to test things together), or significantly increases cognitive overhead of reviewing code.

reactordev 9mo ago

I leverage git submodules and avoid the same pitfalls of monorepo scale hell we had 20 years ago. Glad it works for you though. I feel like this is the path to ARR until you need to scale engineering beyond just you and your small team. The good news here is that the author has those domains segregated out as subfolders so in the future, he/she could just pull that out into its own repo if that time came. Still adverse to the monorepo though, but I understand why it's attractive.

auslegung 9mo ago

Well written, anticipated my questions about pain points at the end except one: have you hit a point yet where deploying is a pain because it’s happening so frequently? I understand there’s good separation of concerns so a change in marketing/ won’t cause conflicts or anything to impact frontend/ but I have to imagine eventually you’ll hit that pain point. But fwiw I’m a big fan of monorepo containing multiple services, and only breaking up the monorepo when it starts to cause problems. Sounds like author is doing that

7777777phil 9mo ago

Interesting approach to giving LLMs full context. My only concern is the "no workspaces" approach; manual cd && npm install usually leads to dependency drift and "it works on my machine" issues once you start sharing logic between the API and the frontend. It’s a great setup for velocity now, but I'm curious if you've hit any friction with types or shared utils without a more formal monorepo tool?

conartist6 9mo ago

I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!

bulbar 9mo ago
My impression is that the world moved on from multirepo to monorepo and I vaguely remember that git submodules have some serious gotchas.
- tedmiston 9mo ago
  https://diziet.dreamwidth.org/14666.html#what-is-wrong-with-git-submodules https://diziet.dreamwidth.org/14666.html#what-is-wrong-with-...
  - conartist6 9mo ago
    yeah, I dunno how else to say it except that if this feature worked right people would like it
maxvirrozeito 9mo ago
For me, integrating features that spans multiple repositories means coordinating changes, multiple PRs, switching branches on many repos to do testing. Quite time consuming. I did use submodules but I find monorepo easier to manage
- conartist6 9mo ago
  I don't doubt that it is. Monorepo tools are much better right now. But monorepos don't compose. They don't branch. They don't scale.

eddd-ddde 9mo ago

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

giancarlostoro 9mo ago
I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and let them get their work done, they will PR when its ready.
- eddd-ddde 9mo ago
  I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.
  - catlifeonmars 9mo ago
    What is JJ?
    - Denvercoder9 9mo ago
      https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj
- sallveburrpi 9mo ago
  squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

radial_symmetry 9mo ago

I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ https://nimbalyst.com/ for. We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks. Internally we have been doing a lot of what they talk about here, doing our design work, business planning, and marketing with Claude Code in our main repo.

fragmede 9mo ago
So the insane thing I do is I don't use worktrees. I am using multiple Claude code instances on the same project doing different things at the same time like one is editing the CSS for the login screen while another one is changing up the settings section of the project.
- hu3 9mo ago
  yep. if the project is large enough, there are usually changes to be made that don't overlap, allowing multiple agents to work concurrently without work trees. for example I can have a prompt writing playwright tests for happy paths while another prompt is fixing a bug of duplicated rows in a table because of a missing SQL JOIN condition.
hckr1292 9mo ago
I’m curious about the authors experience with monorepo for marketing. I’ve found that using static site generators with nontechnical PMs resulted in dissatisfaction and more work for engineers that those PMs could handle independently in Wordpress/Contentful. As a huge believer in monorepo, I’d love to hear how folks have approached incorporating nonengingeers into the monorepo workflows.
scottydelta 9mo ago
> Nimbalyst is SOC-Type 2 certified What does this mean in context of downloadable desktop apps?

sethammons 9mo ago

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of them _will not_ be able to validate and accept some upgrade. Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. Yes, this happens at slightly larger orgs. I've seen it many times. And since you have to design your changes to be backwards compatible already, why not leverage a gradual roll out? Do you update your app lock-step when AWS updates something? Or when your email service provider expands their API? No, of course not. And you don't have to lock yourself to other teams in your org for the same reason. Monorepos are hotbeds of cross contamination and reaching beyond API boundaries. Having all the context for AI in one place is hard to beat though.

kccqzy 9mo ago
I’m not sure why you made the logical leap from having all code stored in a single repo to updating/deploying code in lockstep. Where you put your code (the repo) can and should be decoupled from how you deploy changes. > you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes Of course you design changes to be backwards compatible. Even if you have a single node and have no networked APIs. Because what if you need to rollback? > Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. This is an organizational issue not a tech issue. Who gives that one team the power to hold back large changes that benefit the entire org? You need a competent director or lead to say no to this kind of hostage situation. You need defined policies that balance the needs of any individual team versus the entire org. You need to talk and find a mutually accepted middle ground between teams that want new features and teams that want stability and no regressions.
- ajanuary 9mo ago
  The point is that the realities of not being able to deploy in lockstep erode away at a lot of the claimed benefits the monorepo gives you in being able to make a change everywhere at once. If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.

sails 9mo ago

I like this for adjacent things too. Company website in the same repo means you can find branding material and company tone from blogs, meaning you can generate customer slides, video demos Going further, Docs + Code, why not also store Bugs, Issues etc. I wonder

dheera 9mo ago

The thing I dislike about monorepos is that people don't ship stuff. Multiple versions of numpy and torch exist within the codebase, mitigated by bazel or some other build tool, instead of building binaries and deb packages and shipping actual products with well-documented APIs so that one team never needs to actually touch another team's code to get stuff done. The people who say polyrepos cause breakage aren't doing it right. When you depend across repos in a polyrepo setup, you should depend on specific versions of things across repos, not the git head. Also, ideally, depend on properly installed binaries, not sources.

hckr1292 9mo ago
That makes sense when you depend on a shared library. However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments). To be fair, this problem is not solved at all by monorepos. Basically, only careful use of gRPC (and similar technology) can help solve this… and it doesn’t really solve for application layer semantics, merely wire protocol compatibility. I’m not aware of any general comprehensive and easy solution.
- dheera 9mo ago
  > However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments). In a polyrepo environment, either: - B updates their endpoint in a backward compatible fashion, making sure older stuff still works OR - B releases a new version of their API at /api/2.0 but keeps /api/1.0 active and working until nothing depends on it anymore, releasing deprecation messages to devs of anyone depending on 1.0
  - hckr1292 9mo ago
    Right, so all of that is independent of mono vs poly repo.

supermdguy 9mo ago

How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.

david422 9mo ago
I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.
- Etheryte 9mo ago
  So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.
  - Arainach 9mo ago
    Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
    - Etheryte 9mo ago
      This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
    - hu3 9mo ago

wrs 9mo ago

This is sort of a whole product, but it’s hardly managing the whole company. Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.

PunchyHamster 9mo ago
Yes but AI! AI!
webdevver 9mo ago
i am actually eagerly waiting for someone to show the real-deal: actually everything in a github repo, including 'artfiacts', or atleast those artifacts which can't be reconstructed from the repo itself. maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO." theres a lot of power i think to have everything in one place. maybe github could add the notion of private folders? but now thats ACLs... probably pushing the tool way too far.
- b40d-48b2-979e 9mo ago
  maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO." I don't see how this is any different from most projects where keys and the like are kept in some form of secrets manager (AWS services, GHA Secrets, Hashi Vault, etc.).
- kittoes 9mo ago
  https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resources https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour... How close do you think this is? Deploys everything but the actual backend/frontend code.
- maccard 9mo ago
  At a previous job we put compilers and standard libraries in version control, with custom tooling to pull the right version for what you need. We used p4 rather than git though.

doublet00th 9mo ago

I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea. Here were the downsides we ran into - Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service. - CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything") - Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time. That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released. [1]: https://pangea.cloud/ https://pangea.cloud/

hckr1292 9mo ago
Did you use turbo, buck or Bazel? Without monorepo tooling (and the blood, sweat, and tears it takes to hone them for your use cases), you start hitting all kinds of scaling limits in CI.
- doublet00th 9mo ago
  We had python scripts that generated GitLab CI/CD yaml [1]. Tooting my own horn here, but it was super cool to ship fairly fast for the first year or so. By the end, we had something like 5 MB of yaml, but in order for the GitLab SaaS backend to process it, it took something like 32 gigs of ram on their MergeRequestProcessor SideKiq worker. They had to open a whole epic in order to reduce the memory usage, but I think all that work just let us continue to use GitLab as the number of services we grew increased. They recommended we use something called parent/child pipelines, but it would have been a fairly large rewrite of our logic. [1]: https://docs.gitlab.com/ci/yaml/ https://docs.gitlab.com/ci/yaml/

codegeek 9mo ago

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

NERD_ALERT 9mo ago
Hosting a developer environment remotely that you SSH into is very common. That’s how you would approach working with a monorepo that has any serious size to it.
Carrok 9mo ago
This is probably different between startups and enterprises. My background is purely startups, and I can't imagine not having access to 100% of the code for the company I work.
NeutralWanted 9mo ago
I work at Google, and yes. We use a monorepo for absolutely everything you can think of. But good luck getting that code off a corp device without being caught!
- fragmede 9mo ago
  Android never fully made it into google3. Google is big and does so much stuff and almost everything is in there but there are exceptions!
tn1 9mo ago
While not talked about on HN as much, the big corps doing monorepo use something like Perforce which has "protects" tables allowing very granular access control

codingdave 9mo ago

> When you ask Claude to "update the pricing page to reflect the new limits," it can... wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?

ra_men 9mo ago
AI is turning in to an addiction and crutch for some people.
cadamsdotcom 9mo ago
Code review still exists, you know. AI didn’t magically uninvent “let’s have someone else check this over before it’s shipped”.

c-fe 9mo ago

I like this a lot. Every time I am forced to open Notion or Slite, I just wish so much it would just be .md files in a git repository.

hrdwdmrbl 9mo ago

I love the idea. It's bold. But, I hate it from an information architecture perspective. This is something that is, of course, super relevant given context management for agentic AI. So there's great appeal in doing this. And today, it might even be the best decision. But this really feels like an alpha version of something that will have much better tooling in the near-future. JSON and Markdown are beautiful simple information containers, but they aren't friendly for humans as compared with something like Notion or Excel. Again I'll say, I'm confident that in the near-future we'll start to see solutions emerge that structure documentation that is friendly to both AIs and humans.

williamtrask 9mo ago

"Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything. When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings? The monorepo isn't a constraint. It's a force multiplier." Thank you Claude :)

esafak 9mo ago
It wrote the code, so it's best placed to write the copy too.
- NewsaHackO 9mo ago
  That is exactly right!

johnfn 9mo ago

This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.

ralfhn 9mo ago
You’d think people would at least spend 2 minutes changing obvious tells like “Why This Matters”…
nlh 9mo ago
It's weird it looks like only a small % of comments on here have caught on to the obvious LLM-ness of it all (I missed it the first go-around but on second read, you're is absolutely correct). I'm wondering once the exceedingly obvious LLM style creeps more and more into the public mind if we're going to look back at these blog posts and just cringe at how blatant they were in retrospect. The models are going to improve (and people will catch on that you can't just use vanilla output from the models as blog posts without some actual editing) and these posts will just stand out like some very sore thumbs. (ps all of the above 100% human written ;)
ra_men 9mo ago
It feels like intellectual dishonesty when it's not declared at the top of the article. I have no issues with AI, when the authors are honest about their usage. But if you stamp your name to an article without clear mention that LLMs wrote at least a significant piece of it, it feels dishonest and I disconnect from it.

stego-tech 9mo ago

Honestly, from the enterprise IT perspective? Fuck yes I love this attitude to transparency and code-based organization. This is the kind of stuff that gets me going in the morning for work, the kind of organization and utility I honestly aspire to implement someday. As many commenters rightly point out, this doesn't run the human side of the company. It could, though, if the company took this approach seriously enough. My personal two cents, it could be done as a separate monorepo, provided the company and its staff remain disciplined in its execution and maintenance. It'd be far easier to have a CSV dictate employees and RBAC rather than bootstrapping Active Directory and fussing with its integrations/tentacles. Putting department processes into open documentation removes obfuscation and a significant degree of process politics, enabling more staff to engage in self-service rather than figuring out who wields the power to do a thing. I really love everything about this, and I'd like to see more of it, AI or not. Less obfuscation and more transparency is how you increase velocity in any organization.

jensenbox 9mo ago

Oddly enough, I wrote an article about this very topic recently: https://medium.com/@jensenbox/why-monorepos-are-winning-in-the-age-of-services-and-ai-1210d0a184ed https://medium.com/@jensenbox/why-monorepos-are-winning-in-t...

graphememes 9mo ago

You can still have all the context in one place, just clone the repos to one folder on your machine, problem solved.

shepherdjerred 9mo ago
That introduces the problem of coordinating changes between repositories

Escapade5160 9mo ago

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

talos 9mo ago
Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.
- lawrjone 9mo ago
  I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around. Not to say this post isn't AI generated but you might want a better tool (if one exists)
  - talos 9mo ago
    Hmm I'm curious which blog post tripped it? I tried a few from your site in 2023 and none of them were flagged as AI generated.
  - talos 9mo ago
    Yeah, it's got a real issue with false positives. And I've tried a bunch of other tools (Sapling, ZeroGPT, a few others) and actually GPTZero was the best of the bunch. The others would miss obviously AI generated content that I'd just generated to test them. I've had a blog post kicking around about this for a while, it's CRAZY how much more expensive AI detection is than AI generation. In my mind content generated today with AI "tells" like the above and a general zero-calorie-feel that also trip an AI detector are very likely AI generated.
- teekert 9mo ago
  Pff the mental list of what I can’t use when I write is getting pretty big. Em dashes are done for, as are deep dives, delving, anything too enthusiastic, and Oxford commas… A text either has value to you or it doesn’t. I don’t really understand what the level of AI involvement has to do with it. A human can produce slop, an AI can produce an insightful piece. I rely mostly on HN to tell them apart value-wise.

root_axis 9mo ago

55 business logic services? Sounds extremely overengineered. I'm sure at least half of those services should be consolidated into others.

senbrow 9mo ago
There is no universally "correct" granularity. You could easily scoff the same way about some number of API endpoints, class methods, config options, etc, and it still wouldn't be meaningful without context. It's ok to split or lump as the team sees fit.
- root_axis 9mo ago
  > There is no universally "correct" granularity. There may not be a universally correct granularity, but that doesn't mean clearly incorrect ones don't exist. 50+ services is almost always too many, except for orgs with hundreds or thousands of engineers.

harel 9mo ago

For the purpose of AI Tools, you can also have one workspace, or one directory where multiple repos are cloned to as a parent. Just saying...

bilbo-b-baggins 9mo ago

Good Christ. Imagine having decided that your price structures should be a JSON file instead of persisted in a database and then thinking that any decision made by that person/team is a good idea. I look forward to when we see the article about breaking the monorepo nightmare.

ForHackernews 9mo ago
Depending on how often you need to change your pricing and how many products you offer, flat files might make a lot of sense.
wrs 9mo ago
Sometimes this sort of thing is not a bad idea. If it's a simple data structure that doesn't change very often, you get an admin interface (vi), change tracking, and audit trail for free. Just think of it as configuration rather than data and most folks would think it's normal to do this.

burgerone 9mo ago

Had me interested up until the word "AI"

sandeepkd 9mo ago

I envy this confidence, the less you know the more confident you are.

darepublic 9mo ago

The opening blurb about updating a JSON file and seeing it reflected right away in the live web app just reminds me of a CMS.

throw-12-16 9mo ago

Sounds like a pain in the ass for non developers to contribute. Also, are we just upvoting obvious AI gen marketing slop now?

deleted 9mo ago

[deleted]

ozozozd 9mo ago

I’m not sure how seemingly most of us forgot about the context window being a finite _window_. “It’s all there Claude just read it.” Ok…

suralind 9mo ago

What’s the value proposition? I mean the fact that you have - frontend - backend - website is already confusing to me. I understand that one commit seems nice, but you could have achieve this with e.g. 3 repos and very easily maintain all of them. There’s a bit of overhead of course, but having some experience working with a team that has a few „monorepos” I know that the cost to actually make it work is significant.