[HN Gopher] Everything as code: How we manage our company in one...
___________________________________________________________________
Everything as code: How we manage our company in one monorepo
Author : benbeingbin
Score : 148 points
Date : 2025-12-30 20:05 UTC (2 hours ago)
(HTM) web link (www.kasava.dev)
(TXT) w3m dump (www.kasava.dev)
| giancarlostoro wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| This is where unit testing / integration testing should be
| implemented as guard rails in my eyes.
| ChadNauseam wrote:
| 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 wrote:
| > Rollout should be within a minute
|
| And if it's not, it breaks everything. This is an
| assumption you can't make.
| jvuygbbkuurx wrote:
| 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 wrote:
| 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.
| nithril wrote:
| Is there any concern/issue regarding Claude's context limit?
| deaux wrote:
| 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 wrote:
| What does the flag do? Just allow Claude to access that
| directory?
| qingcharles wrote:
| 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 wrote:
| 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.
| servercobra wrote:
| 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 wrote:
| [delayed]
| reactordev wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My impression is that the world moved on from multirepo to
| monorepo and I vaguely remember that git submodules have some
| serious gotchas.
| tedmiston wrote:
| https://diziet.dreamwidth.org/14666.html#what-is-wrong-
| with-...
| conartist6 wrote:
| yeah, I dunno how else to say it except that if this
| feature worked right people would _like_ it
| maxvirrozeito wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What is JJ?
| sallveburrpi wrote:
| 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
| Denvercoder9 wrote:
| Squashing only results in a cleaner commit history if
| you're making a mess of the history on your branches. If
| you're structuring the commit history on your branches
| logically, squashing just throws information away.
| TheGRS wrote:
| Not everyone develops and commits the same way and
| mandating squashing is a much simpler management task
| than training up everyone to commit in a similar manner.
| esafak wrote:
| Besides, they probably _shouldn 't_ make PR commits
| atomic, but do so as often as needed. It's a good way to
| avoid losing work. This is in tension with leaving behind
| clean commits, and squashing resolves it.
| gbear605 wrote:
| The solution there is to make your commit history clean
| by rebasing it. I often end my day with a "partial
| changes done" commit and then the next day I'll rebase it
| into several commits, or merge some of the changes into
| earlier commits.
|
| Even if we squash it into main later, it's helpful for
| reviewing.
| sallveburrpi wrote:
| We also do conventional commits:
| https://www.conventionalcommits.org/
|
| Other than that pretty free how you write commit messages
| mmh0000 wrote:
| True but. There's a huge trade-off in time management.
|
| I can spend hours OCDing over my git branch commit
| history.
|
| -or-
|
| I can spend those hours getting actual work done and
| squash at the end to clean up the disaster of commits I
| made along the way so I could easily roll back when
| needed.
| tedmiston wrote:
| it's also very easy to rewrite commit history in a few
| seconds.
| mmh0000 wrote:
| If I'm rewriting history ... why not just squash?
|
| But also, rewriting history only works if you haven't
| pushed code and are working as a solo developer.
|
| It doesn't work when the team is working on a feature in
| a branch and we need to be pushing to run and test
| deployment via pipelines.
| trevor-e wrote:
| Good luck getting 100+ devs to all use the same logical
| commit style. And if tests fail in CI you get the
| inevitable "fix tests" commit in the branch, which now
| spams your main branch more than the meaningful changes.
| You could rebase the history by hand, but what's the
| point? You'd have to force push anyway. Squashing is the
| only practical method of clean history for large orgs.
| mattbillenstein wrote:
| This - even 5 devs.
|
| Also rebasing is just so fraught with potential errors -
| every month or two, the devs who were rebasing would
| screw up some feature branch that they had work on they
| needed and would look to me to fix it for some reason.
| Such a time sink for so little benefit.
|
| I eventually banned rebasing, force pushes, and mandated
| squash merges to main - and we magically stopped having
| any of these problems.
| esafak wrote:
| Rebase before creating PR, merge after creating PR.
| William_BB wrote:
| We squash, but still rebase. For us, this works quite
| well. As you said, rebasing needs to be done carefully...
| But the main history does look nice this way.
| literallyroy wrote:
| I'm all ears for a better approach because squashing
| seems like a good way to preserve only useful
| information.
|
| My history ends up being: - add feature x - linting - add
| e2e tests - formatting - additional comments for feature
| - fix broken test (ci caught this) - update README for
| new feature - linting
|
| With a squash it can boil down to just "added feature x"
| with smaller changes inside the description.
| Faaak wrote:
| What about separate, atomic, commits? Are they squashed
| too? Makes reverting a fix harder without impacting the
| rest, no?
| ezfe wrote:
| PRs should be atomic, if they need to be separated for
| reverting, they should be multiple PRs.
| UltraSane wrote:
| "squash results in a cleaner commit history" Isn't the
| commit history supposed to be the history of actual
| commits? I have never understood why people put so much
| effort into falsifying git commit histories.
| catlifeonmars wrote:
| "Falsifying" is complete hyperbole. Git commit history is
| a tool and not everyone derives the same ROI from the
| effort of preserving it. Also squashing is pretty
| effortless.
| alemanek wrote:
| Here is how I think of it. When I am actively developing
| a feature I commit a lot. I like the granularity at that
| stage and typically it is for an audience of 1 (me). I
| push these commits up in my feature branch as a sort of
| backup. At this stage it is really just whatever works
| for your process.
|
| When I am ready to make my PR I delete my remote feature
| branch and then squash the commits. I can use all my
| granular commit comments to write a nice verbose comment
| for that squashed commit. Rarely I will have more than
| one commit if a user story was bigger than it should be.
| Usually this happens when more necessary work is
| discovered. At this stage each larger squashed commit is
| a fully complete change.
|
| The audience for these commits is everyone who comes
| after me to look at this code. They aren't interested in
| seeing it took me 10 commits to fix a test that only
| fails in a GitHub action runner. They want the final
| change with a descriptive commit description. Also if
| they need to port this change to an earlier release as a
| hotfix they know there is a single commit to cherry pick
| to bring in that change. They don't need to go through
| that dev commit history to track it all down.
| normie3000 wrote:
| > you have to make a brand new branch for your next PR
|
| Is there overhead to creating a branch?
| lorey wrote:
| Very interesting points. Would you mind sharing a few examples
| of when cherry-picking is necessary and why atomic changes are
| a lie?
|
| I'm using a monorepo for my company across 3+ products and so
| far we're deploying from stable release to stable release
| without any issues.
| GeneralMayhem wrote:
| Do you take down all of your projects and then bring them
| back up at the new version? If not, then you have times at
| which the change is only partially complete.
| rezonant wrote:
| Nah, these days the new thing is Vibe Deployments, just
| ship the change and pray.
| awesome_dude wrote:
| People that Blue Green are doing that, aren't they?
|
| Canary/Incremental, not so much
| tedmiston wrote:
| each deployment is a separate "atomic change". so if a one-
| file commit downstream affects 2 databases, 3 websites and 4
| APIs (madeup numbers), then that is actually 9 different
| independent atomic changes.
| Eridrus wrote:
| Atomic changes are a lie in the sense that there is no atomic
| deployment of a repo.
|
| The moment you have two production services that talk to each
| other, you end up with one of them being deployed before the
| other.
| ratorx wrote:
| Not sure what GP had in mind, but I have a few reasons:
|
| Cherry picks are useful for fixing releases or adding changes
| without having to make an entirely new release. This is
| especially true for large monorepos which may have all sorts
| of changes in between. Cherry picks are a much safer way to
| "patch" releases without having to create an entirely new
| release, especially if the release process itself is long and
| you want to use a limited scope "emergency" one.
|
| Atomic changes - assuming this is related to releases as
| well, it's because the release process for the various
| systems might not be in sync. If you make a change where the
| frontend release that uses a new backend feature is released
| alongside the backend feature itself, you can get version
| drift issues unless everything happens in lock-step and you
| have strong regional isolation. Cherry picks are a way to
| circumvent this, but it's better to not make these changes
| "atomic" in the first place.
| gorgoiler wrote:
| If your monorepo compiles to one binary on one host then
| fine, but what do you do when one webserver runs vN, another
| runs v(N-1), and half the DB cluster is stuck on v(N-17)?
|
| A monorepo only allows you to reason about the entire product
| as it should be. The details of how to migrate a live service
| atomically have little to do with how the codebase migrates
| atomically.
| djhedges wrote:
| We use a mono repo and feature flag new features which gives us
| the deployment control timing.
| odie5533 wrote:
| What do you use for feature flags?
| emptysea wrote:
| Not OP, but I think building feature flags yourself really
| isn't hard and worth doing. It's such an important
| component that I wouldn't want to depend on a third party
| catlifeonmars wrote:
| If statements?
| radial_symmetry wrote:
| I promise I only self promote when it is relevant, but this is
| exactly what I am building 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 wrote:
| 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.
| hckr1292 wrote:
| 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.
| sethammons wrote:
| 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 wrote:
| 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 wrote:
| 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.
| valicord wrote:
| The point is atomic _code_ changes, not atomic deployments.
| If I want to rename some common library function, it 's
| just a single search and replace operation in a monorepo.
| How do you do this with multiple repos?
| mjr00 wrote:
| > If I want to rename some common library function, it's
| just a single search and replace operation in a monorepo.
| How do you do this with multiple repos?
|
| Multiple repos shouldn't depend on a single shared
| library that needs to be updated in lockstep. If they do,
| something has gone horribly wrong.
| catlifeonmars wrote:
| [delayed]
| mjr00 wrote:
| 100%, this is all true and something you have to tackle
| eventually. Companies like this one (Kasava) can get away with
| it because, well, they likely don't have very many customers
| and it doesn't really matter. But when you're operating at a
| scale where you have international customers relying on your
| SaaS product 24/7, suddenly deploys having a few minutes of
| downtime matters.
|
| This isn't to say monorepo is bad, though, but they're clearly
| naive about some things;
|
| > No sync issues. No "wait, which repo has the current
| pricing?" No deploy coordination across three teams. Just one
| change, everywhere, instantly.
|
| It's literally impossible to deploy "one change"
| simultaneously, even with the simplest n-tier architecture. As
| you mention, a DB schema is a great example. You physically
| cannot change a database schema and application code at the
| exact same time. You either have to ensure backwards
| compatibility or accept that there will be an outage while old
| application code runs against a new database, or vice-versa.
| And the latter works exactly up until an incident where your
| automated DB migration fails due to unexpected data in
| production, breaking the deployed code and causing a panic as
| on-call engineers try to determine whether to fix the migration
| or roll back the application code to fix the site.
|
| To be a lot more cynical; this is clearly an AI-generated blog
| post by a fly-by-night OpenAI-wrapper company and I suspect
| they have few paying customers, if any, and they probably won't
| exist in 12 months. And when you have few paying customers,
| _any_ engineering paradigm works, because it simply does not
| matter.
| jeffbee wrote:
| I really have never been able to grasp how people who believe
| that forward-compatible data schema changes are daunting can
| ever survive contact with the industry at scale. It's extremely
| simple to not have this problem. "design for forwards-backwards
| compatible changes" is what every grown-up adult programmer
| does.
| gnarlouse wrote:
| I think I disagree.
|
| We have a monorepo, we use a server framework with automated
| code generation for API clients for each h service derived from
| OpenAPI.json. One change cascades too many changes. We have a
| custom CI job that trawls git and figures out which projects
| changed (including dependencies) as to compute which services
| need to be rebuilt. We may just not be at scale--thank God. We
| a small team.
| mjr00 wrote:
| Monorepo vs multiple repos isn't really relevant here,
| though. It's all about how many independently deployed
| artifacts you have. e.g. a very simple modern SaaS app has a
| database, backend servers and some kind of frontend that
| calls the backend servers via API. These three things are all
| deployed independently in different physical places, which
| means when you deploy version N, there will be _some_ amount
| of time they are interacting with version N-1 of the other
| components. So you either have to have a way of managing
| compatibility, or you accept potential downtime. It 's just a
| physical reality of distributed systems.
|
| > We may just not be at scale--thank God. We a small team.
|
| It's perfectly acceptable for newer companies and small teams
| to not solve these problems. If you don't have customers who
| care that your website might go down for a few minutes during
| a deploy, take advantage of that while you can. I'm not
| saying that out of arrogance or belittlement or anything;
| zero-downtime deployments and maintaining backwards
| compatibility have an engineering cost, and if you don't have
| to pay that cost, then don't! But you should at least be
| cognizant that it's an engineering decision you're explicitly
| making.
| Groxx wrote:
| atomic updates in particular is one of those things that sounds
| good to the C-suite, but falls apart extremely badly in the
| lower levels.
|
| months-long delays on important updates due to some large
| project doing extremely bad things and pushing off a minor
| refactor endlessly has been the norm for me. but they're big so
| they wield a lot of political power so they get away with it
| every time.
|
| or worse, as a library owner: spending INCREDIBLE amounts of
| time making sure a very minor change is safe, because you can't
| gradually roll it out to low-risk early adopter teams unless
| it's feature-flagged to hell and back. and if you missed
| something, roll back, write a report and say "oops" with far
| too many words in several meetings, spend a couple weeks triple
| checking feature flagging actually works like everyone thought
| (it does not, for at least 27 teams using your project), and
| then try again. while everyone else working on it is also stuck
| behind that queue.
|
| monorepos suck imo. they're mostly company lock-in, because
| they teach most absolutely no skills they'd need in another job
| (or for contributing to open source - it's a brain drain on the
| ecosystem), and all external skill is useless because every
| monorepo is a fractal snowflake of garbage.
| catlifeonmars wrote:
| > Having all the context for AI in one place is hard to beat
| though.
|
| Seems like a weird workaround, you could just clone multiple
| repos into a workspace. Agree with all your other points
| though.
| sails wrote:
| 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 wrote:
| 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 wrote:
| 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.
| supermdguy wrote:
| 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 wrote:
| I do it naively. Maintain the backend and frontend separately.
| Roll out each change in a backwards compatible manner.
| Etheryte wrote:
| So in short you don't share types. Manually writing them for
| both is easy, but also tedious and error prone.
| Arainach wrote:
| 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 wrote:
| 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.
| jim201 wrote:
| I used to dread this approach (it's part of why I like
| Typescript monorepos now), but LLMs are fantastic at
| translating most basic types/shapes between languages. Much
| less tedious to do this than several years ago.
|
| Of course, it's still a pretty rough and dirty way to do it.
| But it works for small/demo projects.
| denysvitali wrote:
| protobuf?
| esafak wrote:
| I have a library translate the backend types into Typescript.
| What language do you use on the back?
| shepherdjerred wrote:
| Typespec is up and coming. Otherwise there are plenty of
| options like OpenAPI
| programmarchy wrote:
| FastAPI -> OpenAPI -> openapi-typescript
| wrs wrote:
| 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 wrote:
| Yes but AI! AI!
| webdevver wrote:
| 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 wrote:
| 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.).
| doublet00th wrote:
| 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/
| hckr1292 wrote:
| 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.
| codegeek wrote:
| 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 wrote:
| 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 wrote:
| 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.
| codingdave wrote:
| > 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?
| c-fe wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| It wrote the code, so it's best placed to write the copy too.
| NewsaHackO wrote:
| That is exactly right!
| johnfn wrote:
| 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 wrote:
| You'd think people would at least spend 2 minutes changing
| obvious tells like "Why This Matters"...
| nlh wrote:
| 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 ;)
| stego-tech wrote:
| 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 wrote:
| Oddly enough, I wrote an article about this very topic recently:
| https://medium.com/@jensenbox/why-monorepos-are-winning-in-t...
| graphememes wrote:
| You can still have all the context in one place, just clone the
| repos to one folder on your machine, problem solved.
| shepherdjerred wrote:
| That introduces the problem of coordinating changes between
| repositories
| Escapade5160 wrote:
| This article reads like 4o wrote it. It's so exhausting not being
| able to find content produced by a human being.
| talos wrote:
| 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 wrote:
| 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 wrote:
| 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.
| talos wrote:
| 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.
| teekert wrote:
| 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.
| talos wrote:
| Did this not read as AI generated to you?
| 0xbadcafebee wrote:
| What's exhausting is seeing people complain about AI writing.
| What exactly are you looking for instead? A poorly written
| article?
| root_axis wrote:
| 55 business logic services? Sounds extremely overengineered. I'm
| sure at least half of those services should be consolidated into
| others.
| harel wrote:
| 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...
___________________________________________________________________
(page generated 2025-12-30 23:00 UTC)