[HN Gopher] Company as Code
___________________________________________________________________
Company as Code
Author : ahamez
Score : 203 points
Date : 2026-02-05 12:56 UTC (10 hours ago)
(HTM) web link (blog.42futures.com)
(TXT) w3m dump (blog.42futures.com)
| mhitza wrote:
| The images really detract from the subject.
|
| I've used to do something like this, on a smaller scale and
| dubbed it "organization as code". As long as you have good enough
| providers for Terraform/Pulumi you can declaratively specify a
| lot of the interconnected stuff in a company.
|
| I built this around GitHub as the indentity provider as my
| interest was declaratively defining repository access control,
| while also being able to use users public ssh keys to
| (re)provision services to get them access automatically.
| captn3m0 wrote:
| I've done the same thing and I would not call it anywhere near
| org-as-code either. An organization is much more than a list of
| responsibilities, people, and compliance requirements.
|
| For the latter, we already have policy-as-code tooling that
| actually works.
| mhitza wrote:
| Might be a second language thing. Organization for me is
| stronger related to the root word organize; label, classify,
| cluster, etc. than something pertaining to processes and
| procedures.
| kevmo314 wrote:
| In the future, laying off half the company will be just one
| terraform apply away.
| dgxyz wrote:
| To be fair I've seen some terraform fuck ups that that nearly
| did that already.
|
| Fortunately AWS doesn't let you delete S3 buckets with files in
| them without emptying them first...
| askl wrote:
| Or one AI agent tasked with optimizing the company finances.
| philipwhiuk wrote:
| This sort of approach is likely intractable.
|
| A company is more than the function of it's org chart.
|
| There's business description being uncaptured sporadically in
| every Slack message, watercooler moment and email. (two of those
| are much easier than the other).
|
| If you boil someone's actual job down to a HR job spec and assume
| that will suffice... you'll produce both absurdly long HR job
| specs and still fail to capture the entirety of someone's role.
| Ancapistani wrote:
| > A company is more than the function of it's org chart.
|
| Of course - but the org chart is _context_. It reflects how the
| work of individuals contributes to the whole (or at least, it
| should!)
|
| Having all this in "code" means AI can put it into context.
| conception wrote:
| This is not a bad idea but this person basically reinvented LDAP.
| Everything he wanted to do is already in LDAP, much already in
| Active Directory.
| ActionHank wrote:
| All they need to do now is slap AI on it and they'll have bags
| of cash delivered to their door.
| conception wrote:
| LAIDBACK - Lightweight AI Directory Barely Actually Checking
| Krendentialz?
| tekno45 wrote:
| They started with their schema and everything they said just
| screamed Active Directory.
|
| Right down to the low code interface for changes.
| hkhanna wrote:
| I do this, more or less, for my small law firm. Employee and
| client information are stored in Recfiles and accessed with GNU
| Recutils. Adding or changing is a pull request, and all sorts of
| GitHub actions run. Works pretty well!
| CountVonGuetzli wrote:
| Wat, how have I never heard of this! Very cool. Do you have any
| insights you could share on your own setup, what worked well
| and what didn't? Are you just storing information in plaintext,
| or do you use some visualization libraries to make consuming
| the information a bit easier as well? Very curious about your
| setup.
| squeefers wrote:
| beyond the source controlled database, is it doing the same as
| what the article describes? ie enforces requirements etc
| treetalker wrote:
| +1 would love to see a video or read an extended write-up of
| how you implemented and work with your system on a daily basis,
| and what exactly it does for you
| squeefers wrote:
| I suspect hes designed a system for HIS company, which is in a
| data heavy industry. this doesnt apply to most other types of
| company, and I suspect when he tries to actually do it, it falls
| apart when he tries to define any requirement or obligation that
| stems from legislation. If the law was a coherent and unambiguous
| specification, thered be no problem, but the reality of it is
| messy and not so easily defined.
| jbs789 wrote:
| Made me laugh bc you're right - there are a whole host of
| decisions that are better left undocumented and ambiguous.
| arnvald wrote:
| It's all cool as long as you keep all of this up to date, and
| that requires a lot of scrutiny and discipline.
|
| Once I had to go through a security audit at a job I had. Part of
| it was to show managing secret keys and who had access to them.
| And then I realized that the list of people who had access to one
| key was different than the list of the code owners of the service
| I was looking at, which was yet different than the list of the
| administrators of that service. 3 different sources of truth
| about ownership, all in code, all out of sync.
| chrisjj wrote:
| > 3 different sources of truth about ownership
|
| I see only 1.
|
| Admin, access <> ownership.
| d4mi3n wrote:
| I always thought of this as authority, accountability, and
| responsibility of a thing. Ideally one group or person has
| all three. In practice you'll have many entities with some
| combination of the three.
| chrisjj wrote:
| I am sure mere access does not imply any kind of ownership.
| Philip-J-Fry wrote:
| Isn't the point that this is the source of truth?
|
| If someone needs access to a secret, you would implement it in
| this DSL and commit that to the system. A side effect would run
| on that which would grant access to that secret. When you want
| to revoke access, you commit a change removing that permission
| and the side effect runs to revoke it.
| vlfig wrote:
| Eminently doable, yes.
|
| Two notes:
|
| - I'm not convinced the graph is necessarily cyclic. Often two
| codependents are actually dependent on some common bits and
| otherwise independent.
|
| - this is essentially deterministic propagation of configuration
| (think dhall, jsonnet, etc) plus reconciliation loops for
| external state, terraform style -- not dissimilar to how the rest
| of CI/CD should operate, in fact my view is this is an extension
| of CI/CD practices up the value stream.
|
| I'm definitely strive for something like this when possible.
| amelius wrote:
| > but a living, breathing digital representation of our company
|
| It is breathing already, in the form of humans doing it.
|
| No need to transform it into a static inflexible code thing.
| sshine wrote:
| You're citing the article mid-sentence. The full sentence is:
|
| > _Imagine if we could represent our entire organisational
| structure programmatically instead--not a static picture, but a
| living, breathing digital representation of our company that
| can be versioned, queried, tested, and automatically verified._
|
| So yeah, the organisation is living and breathing by virtue of
| the humans inside of it.
|
| But the representation of its organisational structure refers
| to a picture of an org chart.
|
| Non-tech people also aspire to have the entire org structure
| represented digitally.
|
| But in static, proprietary binary formats in file repositories
| that can only be manually queried.
|
| Our code is already checked into version control and can be
| programmatically accessed via CI, agents, etc. Our software
| production environments can already be queried programmatically
| via APIs. Our issue trackers have hooks that react to support
| tickets, pull requests, CI. Then there's an airgap where the
| rest of the org sits with Word documents and pushes digital
| paper around. Artifacts delivered to customers that must be
| manually copied, attached, downloaded by hand.
|
| The dream is that modern software development practices would
| propagate throughout companies.
|
| Automate all the things!
| danielrothmann wrote:
| Thanks for sharing!
|
| I wrote this post some time ago, and more recently built a thing
| to do roughly this for my small business:
| https://github.com/42futures/firm
|
| Had it in practice for about 4 months now and happy so far. It
| works for me, at my small scale. Hoping to share a follow-up with
| lessons learned soon.
| gearhart wrote:
| This is incredibly cool.
|
| Licensing it as AGPL-v3 throws up an interesting question -
| given the thing this produces is your company as code, if you
| use this does your entire company count as a larger work that
| would need to be open sourced? Or is there an explicit
| distinction between the "firmware" (excuse me) and the work
| product?
| jasonpeacock wrote:
| Licensing generally applies only to the thing being licensed
| and not its output.
|
| Otherwise all software written with a GPLv3 editor would also
| be GPLv3...or all software built with a GPLv3 compiler would
| be GPLv3. (Neither are true)
| ronsor wrote:
| That's because the output isn't a derivative work of the
| licensed software.
| 1dom wrote:
| I always felt the idea of trying to align your code, policy,
| software and infrastructure so it's easy to do compliance is the
| bread and butter of devops and devsecops in a regulated
| environment,
|
| Is this an article by someone who's just done ISO 27001 for the
| first time and realised that?
| Shank wrote:
| > However, when describing and managing our company, we resort to
| digital paper and tidbits of info distributed across people in
| the building.
|
| The perception that ISO/IEC 27001:2022 is simply an exercise in
| document creation and curation is frustrating. It is not, but an
| auditor cannot be in your company for a year or three, so the
| result is the next best thing: your auditor looks at written
| evidence, with things like timestamps, resumes, meeting minutes,
| agendas, and calendars, and concludes that based on the evidence
| that you are doing the things you said you're doing in your
| evidence reviews and interviews.
|
| The consequence if you are _not_ doing these things happens if
| you get sued, if you get yelled at by the French data protection
| regulator, or if you go bankrupt due to a security incident you
| didn 't learn from, and your customers are breathing down your
| neck.
|
| All of the documentation in the world doesn't mean you actually
| do the things you write down, but we have to be practical: until
| you consider these things, you aren't aware of them. You can read
| the standard and just do the best practices, and you'll be fine.
| The catch is that if you want the piece of paper, you go to an
| auditor, and people _buy things_ because that paper means that
| there is now an accountability trail and people theoretically get
| in trouble if that turns out to be false.
|
| It's like the whole problem with smart contracts is that you
| can't actually tether them to real world outcomes where the smart
| aspect falls apart (like relying on some external oracle to tell
| the contract what to do). Your customers care about ISO because
| your auditor was accredited by a body like ANAB to audit you
| correctly, and that reduces the risk of you botching some
| information security practice. This means that their data is in
| theory, more safe. And if it isn't, there is a lawsuit on the
| other end if things go awry.
| jesucresta wrote:
| I feel like this is kind of missing the point that companies are
| mainly a group of humans and their roles and responsibilities
| matter to them emotionally. Managing those expectations and
| feelings can only be done by other humans that feel empathy (good
| managers) and abstracting such relationships onto something that
| can be "versioned, queried, tested, and automatically verified"
| might create a shitty soulless place to work.
| keyle wrote:
| You are describing essentially a healthy company.
|
| You're on a tech news website as a reminder.
| richardlblair wrote:
| Yes - the author's observations are not wrong. Companies, on
| paper, are logical. However, as one professor told us in
| college "All companies are perfect until you introduce the
| humans".
|
| Humans are messy. Humans work outside of whatever system you
| create. You can codify all your things all you want, it simply
| will not capture the operational complexity of a business run
| by humans.
|
| The problem needs to be flipped on its head. LLMs give us the
| capacity to do just that. It's far more accurate to analyze
| what the humans are doing, note deviations and follow up on
| those where regulatory compliance is required. This captures
| both written processes as well as their practical
| implementations.
| nicklucking wrote:
| Exactly this and its a blind spot in the article. LLM's /
| orchestrated specialist agents can query SOP's, policy docs,
| compliance docs. Having humans build these artifacts in code
| isn't really needed at this point. Maybe if there is an
| interim format LLM's can use that save tokens / time / etc.
| Wouldn't assume that looks exactly like exactly what human
| coders would have used the past though.
| kukkeliskuu wrote:
| Anything can be used for the good or for the bad. Defining how
| the organization is structured and how it operates usually is
| usually not about how people really do their actual work --
| unless there are safety etc. regulations that must be met. Many
| enterprises are in constant chaos, which stresses people out.
| Adding some structure to it helps to alleviate that stress. For
| example, if there is a good template to document something, you
| don't have to start from the scratch. Of course, you could also
| go all in automate all your "management", in order to avoid
| talking with your employees. I don't think that will end well.
| kukkeliskuu wrote:
| My company has been working for some years now on usm.tools
| (https://usm.tools/public/landing/), based on very similar
| approach.
|
| USM tools is based on Unified Service Management (USM) method,
| which provides the necessary concepts to take the the vision one
| step further. The core idea is similar however: everything a
| company does is a service, and services can be defined as data.
| The surprising finding from USM is that in practice it is
| possible to meaningfully define any service only through five
| types of processes.
|
| As services are data, you can have multiple views on that data.
| And as all data is in standardized format, it becomes possible to
| make generic cross-references between USM and for example ISO27K
| as rules that refer to your data, and those rules can be
| evaluated. As a result, you can see your ISO27K compliance on a
| dashboard in real-time.
| crashabr wrote:
| Would you be able to share more? I lead a tiny non-profit org
| doing data literacy mentoring and I've been meaning to move
| more of our process docs to Logseq. Although I probably don't
| need a tool of the level of sophistication of usm.tools, I
| could take inspiration from your core ideas for our homegrown
| system.
| WilcoKruijer wrote:
| The DSL described in this post really resonates with me. I
| recently worked on a programming language that uses similar
| structures [0]. It lets the user define entities and their shape
| (Role, OrganisationalUnit, Person in this post) and entries for
| those entities. It contains a small scripting API that can be
| used to derive information from these "facts". Company as code
| could definitely be implemented on top of this.
|
| [0] https://thalo.rejot.dev/blog/plain-text-knowledge-management
| clcaev wrote:
| Well developed and maintained Standard Operating Procedures (SOP)
| go along way towards repeatable human processes. The hard part is
| finding the organizational discipline to use/maintain them.
| estsauver wrote:
| I think the closest that this has come is in the form of GitLab,
| which pretty famously did a ton of the corporate work in the
| format of a very open Handbook (https://handbook.gitlab.com/)
|
| In the early years, it was extremely, extremely open and
| comprehensive. I've definitely looked through it when I wasn't
| sure how to handle something at work.
| monkeydust wrote:
| That's pretty cool. Wonder if it is deployed and updated
| religiously still. If they wanted to deploy an 'Agent' worker
| that source is goldmine for context.
| vidarh wrote:
| I don't know about "religiously" but as of right now it was
| last updated 16 minutes ago:
|
| https://gitlab.com/gitlab-com/content-sites/handbook
| vidarh wrote:
| And that site is available as a git repository - on Gitlab of
| course:
|
| https://gitlab.com/gitlab-com/content-sites/handbook
| greatgib wrote:
| I think that it is a narrow view of a "developer" that imagine
| reinventing what basically already exist in decade with
| HR/"people management" management software that are widely
| distributed. It is sometimes also done by big ERP and basically
| available in any big directory and access management platform
| like Microsoft Entra ID (or whatever is the last current name)
| and co...
|
| In some big companies, for expenses or performance reviews you
| have a terrible stack of relationship info and logic involved.
|
| We could even say somehow that the first big entreprise software
| were creating with that kind of purpose for the modern IT area.
|
| The worst limitation to all of this is users being lazy to input
| all the info that might be required, or updating it. For example,
| how many of you never filled their "address" in their record in
| the big company internal directory portal because it looks
| useless and is not mandatory?
| dlojudice wrote:
| As a programmer and founder, I think the idea is incredible, I
| would just change the understanding of "Code", given that what
| we've been hearing most lately is that "a markdown file is all
| you need".
|
| I think it's not too far-fetched to think about standards,
| cultures, guardrails, compliance, etc. being documented,
| versioned, but more importantly, verifiable and applicable. In
| natural language, no code needed.
| zjaffee wrote:
| Isn't this essentially just trying to reinvent ERP (i.e. what SAP
| has built a 207 billion dollar company at time of writing on and
| 90% of fortune 500 companies along with endless other large
| organizations use).
|
| One can argue that ERP as code is higher value than whatever it
| is right now, but to act like this is a totally new idea is
| insane.
| dmd wrote:
| I worked in a place where basically _everything_ that happened
| in the company was implemented as actions within Lotus Notes.
|
| While the choice of implementation and performance were abysmal
| (Notes was a great/the only choice when the decision was made
| but 25 years later not so much), the actual idea was amazing
| and it worked extremely well.
| bonsai_spool wrote:
| > the actual idea was amazing and it worked extremely well.
|
| What do you think are the reasons it worked so well? Any
| anecdotes of why it was so effective?
| martythemaniak wrote:
| Interestingly, reading about Yegge's Gas Town got me thinking
| about this topic. Gas Town aims to create a "dark software
| factory" where agents organize themselves to build software
| autonomously with only high-level human direction, so Yegge
| created a weird rube goldberg fever dream of cats, preachers,
| diggers, mayors and god knows what else. But why? We already have
| real human organizations staffed and structured in particular
| ways that are able to deliver software, why not follow that
| pattern? With something like this, agents can start with a
| generic software dev shop and iterate on their own organization,
| instead of Yegge manually dreaming up what roles and
| relationships should exist.
| miohtama wrote:
| I recommend book Accelerado by Charlie Stross:
|
| Um." Manfred finds it, floating three tiers down an elaborate
| object hierarchy. It's flashing for attention. There's a priority
| interrupt, an incoming lawsuit that hasn't propagated up the
| inheritance tree yet. He prods at the object with a property
| browser. "I'm afraid I'm not a director of that company, Mr.
| Glashwiecz. I appear to be retained by it as a technical
| contractor with nonexecutive power, reporting to the president,
| but frankly, this is the first time I've ever heard of the
| company. However, I can tell you who's in charge if you want."
| "Yes?" The attorney sounds almost interested. Manfred figures it
| out; the guy's in New Jersey. It must be about three in the
| morning over there. Malice--revenge for waking him up--sharpens
| Manfred's voice. "The president of http://agalmic.holdings
| .root.184.97.AB5 is http://agalmic.holdings .root.184.97.201. The
| secretary is http://agalmic.holdings .root.184.D5, and the chair
| is http://agalmic.holdings .root.184.E8.FF. All the shares are
| owned by those companies in equal measure, and I can tell you
| that their regulations are written in Python. Have a nice day,
| now!"
| Multicomp wrote:
| thanks for the recommendation, I've put a hold on it for my
| library now.
|
| This article reminds me of another book [1] called Holacracy
| where how a business is run is systematized according to other
| pre-defined principles. David Allen, a productivity trainer,
| used it at his own company for several years before eventually
| moving away from it because the ongoing overhead to keep its
| system up was too much.
|
| I wonder if this system will end up like that as well. I love
| the idea, but I think humans operate at a squishier level than
| our computers do, there's a risk of 'massive bureaucratic
| dehumanization and inflexible processes' and the Iron Law of
| Organizations that make such efforts as that book and this
| article fraught with peril. Taylorism has its limits.
|
| But hey, if this works, I'll be excited to see more businesses
| adopting better practices and less painful fumbling around
| trying to do practices in an organic or unplanned way.
|
| [1] https://www.holacracy.org/blog/dac-ceo-reflects-on-
| holacracy...
| AceJohnny2 wrote:
| Accelerando's algorithmic company structure and (near?)DDoS the
| corporate legal system is the one idea from Accelerando that
| has stuck with me the most over the 20 years since I first read
| it, and I came here to make the exact same reference.
|
| (that, and the notion of Exocortex, which is what I've named
| some of my smartphones...)
| thaack wrote:
| This is essentiality the concept of LDAP/Active Directory.
| qwertyuiop_ wrote:
| The OP doesn't understand the "gray zone" corporations operate.
| Pretty much every interaction, decision and actions operate in
| this domain. Ambiguity and intentional compartmentalization on a
| need to know basis.
| NickNaraghi wrote:
| We tried this at Hats Protocol, I think you'll find our approach
| very aligned! https://blog.hatsprotocol.xyz/organizational-graphs
|
| We came at it from the perspective of DAOs, which was helpful at
| first but ultimately limiting. I think a non-blockchain version
| of this will take off. Tailscale is in a good position to do it.
|
| Our earned insight is that you need to build the right primitive
| for delegation that works up and down the org. Our latest
| thinking on that is what we call a "Trust Zone" - more details
| here: https://blog.hatsprotocol.xyz/making-daos-work
|
| You can ignore the "DAO" parts. Happy to answer any questions,
| I'm still very inspired by this line of inquiry.
| adarsh2321 wrote:
| Thanks for sharing your experience with implementing a similar
| concept at Hats Protocol! The idea of a "Trust Zone" for
| delegation sounds intriguing. Have you encountered any specific
| challenges in building and maintaining these organizational
| structures programmatically?
| chockablock wrote:
| Are you a bot or bot-assisted? Repeating back the content of
| a comment and then asking a generic follow-up is a strange
| pattern.
| gglitch wrote:
| If I had the capacity to take on this kind of modeling project
| right now, I'd probably lean toward Prolog or something like an
| OWL/Protege ontology. Then it could just metastasize to the
| limits of my time and neurochemistry.
| brazzy wrote:
| "Code" is absolutely the wrong word here. There's nothing
| executable about it.
|
| It's a _model_. And it will inevitably be incomplete and out of
| data, because the map is not the territory[1]
|
| Of course, the same is true about the unstructured documents he
| laments, and whatever is done with those documents could probably
| sped up a lot this way, _probably_ enough to justify the cost of
| building and maintaining it.
|
| But the more advanced use cases he imagines run a big risk of
| making very costly decisions based on an incomplete or outdated
| model.
|
| [1]: https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
| alexsmolen wrote:
| I love this idea despite the real world operational challenges -
| most people with governance responsibilities in organizations
| don't want to code, and code is often too precise to model messy
| social/organizational context without constant tweaking, tending,
| and exception management.
|
| I'm an advocate for bringing software culture to GRC, or as it's
| sometimes called "GRC Engineering". While there are plenty of
| products to automate evidence generation for auditors, the
| underlying policies and documents that they prescribe are usually
| still old-school Word/PDF-style boilerplate junk.
|
| I'm working on an open source project for security
| policies/processes/standards that map back to underlying
| frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown
| with YAML frontmatter metadata, interlinks generated
| automatically, site is published via GitHub actions.
|
| The code is at https://github.com/engseclabs/graphgrc, and you
| can see an example published site here
| https://graphgrc.engseclabs.com.
|
| Would love to know if others find it useful or have built similar
| systems.
| Terretta wrote:
| > _I 'm working on an open source project for security
| policies/processes/standards that map back to underlying
| frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are
| Markdown with YAML frontmatter metadata, interlinks generated
| automatically, site is published via GitHub actions._
|
| > _Would love to know if others find it useful or have built
| similar systems._
|
| Yes, to both for over a decade now, and by now there are many
| so one doesn't need to rewalk the whole path, some are
| developed in open on GitHub.
|
| Commercial firms have built on that for live monitoring of the
| mappings, although don't scratch at that too hard, it's
| generally mostly (a) self-selected subsets of controls, and (b)
| manually self-reported at the end of the day.
|
| Product examples: https://delve.co or
| https://safebase.io/products/trust-center
|
| Applied example: https://trust.openai.com
|
| Have you Googled this or talked to large firms (e.g. banks)
| that care about avoiding footfalls with regularly scheduled
| regulator exams? Writing your own shows you grok the concept,
| many need (well paid!) help applying something off the shelf or
| from OSS.
| alexsmolen wrote:
| In my research I haven't come across the prior art you
| suggest exists. The trust centers you linked aren't fungible
| with what I'm building with GraphGRC. The idea is to make all
| your security docs just a GitHub repo with structured
| markdown that permits useful automation (e.g. generating
| linked internal site, validating all docs have been
| "reviewed" annually by checking metadata, change control via
| PR, etc.)
|
| There are plenty of GRC products out there and are popular
| for good reasons, but I don't think any of them are
| Git/Markdown/developer-first.
| stego-tech wrote:
| This is not a new or novel idea. I proposed such a thing at the
| start of my career in tech, and repeatedly propose it when I feel
| I have ears willing to listen.
|
| The problem - and I do mean _the_ problem, the _only_ problem -
| is the threat this poses to power dynamics in the organization.
|
| Compliance people do not benefit from their outputs being readily
| searchable and indexed like this, because it means there's less
| need for them. Executives and leaders do not benefit from this,
| because they're increasingly hired specifically _because_ of
| their knowledge of various compliance frameworks. The people
| whose power derives from this knowledge and expertise are
| overwhelmingly the people in charge of the company and its
| operations, and they benefit more from blocking it outright than
| implementing it.
|
| Don't get me wrong, I _love_ this idea. I _love_ transparency in
| organizations, because it makes it infinitely easier to identify
| and remediate problems beyond silo walls. It's peak cooperation,
| and I am all for it.
|
| I also do not see it happening at scale while competition is
| considered the default operating mode of society at large. That
| said, I would love to work for an organization placing importance
| on this degree of internal cooperation. I suspect I'd thrive
| there.
| 9rx wrote:
| _> The problem - and I do mean the problem, the only problem -
| is the threat this poses to power dynamics in the
| organization._
|
| And expertise, to be fair. Documentation as code is what we in
| the software industry call testing/type systems. The vast
| majority of developers cannot even write a good test for their
| code (if they are willing to even try at all), let alone their
| eyes completely glazing over if you ask them to write, like, an
| Rocq proof. And that's people who live and die by code, not
| business people who are layers removed from the activity.
| redanddead wrote:
| "Compliance" as we know it today is going away
| NetOpWibby wrote:
| > That said, I would love to work for an organization placing
| importance on this degree of internal cooperation. I suspect
| I'd thrive there.
|
| I've been looking for such a org my entire career but recently
| resigned myself[1] to the fact it'll probably not happen unless
| I come into a situation when I can create it myself.
|
| ---
|
| [1] <https://blog.webb.page/WM-081>
| observationist wrote:
| It constrains power and makes decisions auditable and holds
| those with power accountable to guidelines. Management doesn't
| like this paradigm for the very same reasons big tech platforms
| make conduct and moderation guidelines vague and nonspecific.
| It frees them up to remove, penalize, fire, and otherwise exert
| power for reasons they can't explicitly justify.
|
| It's exactly the same paradigm the EU and countries around the
| world are avoiding - denying due process in things like freedom
| of press and expression, because they feel it allows them
| flexibility in suppressing and "managing" speech, people, and
| groups they deem problematic.
|
| Having an explicit rule of law constrains the exercise of
| power. Those looking to wield power will never like that.
| jt2190 wrote:
| > I also do not see it happening at scale while competition is
| considered the default operating mode of society at large.
|
| You don't even need competition between people and orgs, just
| between solutions that work more-or-less equally but come with
| different second-order tradeoffs. Consider two approaches that
| solve a company's problem equally but create different amounts
| of work for different people in the organization. Which
| solution to choose? Who gets to decide, based on what criteria?
| As soon as even a little scale creeps in this is inescapable.
| majormajor wrote:
| What prevents people from not doing what the policy says? Since
| neither "paper doc" policy nor "code policy" actually
| constrains humans from trying to exploit or work around the
| system, oversight and compliance still seem like messy human
| functions. Does this just become "more structured compliance
| documentation"? Which sounds nice, but not dramatically
| different.
|
| And on the creation side, what prevents political fights over
| what goes into the "code policy" of exactly the same sort that
| lead to compromises or oddities in paper policies?
| agumonkey wrote:
| Any books about workgroup power dynamics ? i'm fascinated
| (morbidly in a way) by that
| willhslade wrote:
| Harvard Business Review's Office Politics. Or any intro
| Industrial Psychology textbook.
| kukkeliskuu wrote:
| Keith Johnstone: Impro
| ineedasername wrote:
| There's plenty of software that does this sort of thing, often
| industry specific but plenty that aren't. You don't see it "as
| code" in the raw like this article wants mainly because a company
| doesn't deal with this information in such a non-integrated way,
| they do so as part of a more integrated whole. Monolithic ERP
| suites are probably the best example, and when done well it
| really does make a whole host of things easier and more seamless,
| like compliance modules that run defined routines that track with
| policy as implemented in operational modules.
| djeastm wrote:
| Massively complex cells of living organisms have their entire
| functionality encoded in DNA, so why can't a business encode
| their functionality, too?
| graybeardhacker wrote:
| Two major factors I see a impediment to this: 1. Most management
| doesn't understand it and therefore won't champion it. 2. Those
| few that do understand it will resist it because it reduces the
| need for management and process.
|
| This is similar to the Bible being in a dead language only
| understood by priests.
|
| But how amazing would it be if everything from company policy to
| product specifications was in a format that could be
| programmatically accessed and tracked? When/if you needed a
| document you would access it from an artifactory where it had
| been generated and versioned automatically?
|
| It may very well be that LLMs will push this idea to the
| forefront. PDFs and Word Docs suck for AI interaction. As we
| incorporate LLMs into our businesses it might be a natural
| progression to move toward databases, LaTex, code and source
| control for documentation and policy.
| titanomachy wrote:
| The New Testament is actually in Greek, if you go to any church
| in Greece they are reading from it in the original language and
| people understand it fine.
| InitialLastName wrote:
| Virtually none of the Bible was written in a currently-dead
| language. Only small bits were written in Aramaic, and Koine
| Greek and Biblical Hebrew are pretty much comprehensible to
| modern Greek and Hebrew speakers.
|
| Even the Christian era of the Bible being distributed in
| Latin made perfect sense since it was originally mostly being
| distributed to people who spoke Latin with questionable
| accents (and where Latin was the language everyone who was
| literate was literate in).
| WestCoader wrote:
| >Reimagining organisational structure *for the digital age.*
|
| If you're just now thinking about it in this context, then you're
| about two decades too late.
| tracker1 wrote:
| I would probably adapt a slightly different strategy/structure...
| probably using a git repository with markdown files and a mix of
| front-matter and TS with a DSL library for rules processing.
|
| The cold storage is a combination of directory structures and
| markdown files with appropriate front-matter. This could then be
| queryable directly, or via normalization into a database that
| represents the same data. By being markdown, you can write
| rules/policies in a longer/legalize format that Management/HR and
| Employees can read and understand... port to web layouts for
| looking at and searching while having a structure that is
| reasonably developer friendly... the relationships would be
| similar, but each entity would be represented with a markdown
| file with its' own front matter and references to other
| documents.
|
| Just my own thoughts on this.
| sidsud wrote:
| isn't this what HRIS/ERP systems do under the hood? or am I
| missing something here?
| redanddead wrote:
| 1. There are many organizations invested in keeping the
| disconnected status quo 2. The true things you want to connect
| are owned by giants that are slow and dont trust or need you 3.
| You need to play by the big players rules or get nowhere here
| smithkl42 wrote:
| Am I the only one who is mystified by this whole idea? People
| aren't CPU's. Good luck getting them to follow the code that you
| thought you were using to define their roles. On the contrary,
| what makes any complex system work is flexibility. And yes, if
| that calls into question the whole regulatory regime some
| companies (believe they) live under ... well, yes.
| hunterpayne wrote:
| Also, would you even want it to? I've worked for companies with
| very rigorous compliance before. They are dead companies
| walking in most cases. As soon and their business model
| required/requires any significant change, they are toast. This
| is because these types of rules can't possibly cover all cases,
| just the ones the managers know about. Innovation requires
| flexibility and creativity and rules based systems are the
| opposite of that. By their very nature, they introduce the
| exact situations the rules can't cover.
| NetOpWibby wrote:
| The cyclical relationship graph this article mentions is doable
| with Gel[1], my favorite database (the team building it recently
| got acquired by Vercel so the database is in community's hands
| now).
|
| ---
|
| [1] <https://www.geldata.com>
| maebert wrote:
| I love the vision, but it glosses over the most important
| difference between Infrastructure and Companies.
|
| Infrastructure as code is prescriptive. The code is the source of
| truth, and the world gets crested from it.
|
| Company as code is descriptive. It is constantly catching up to
| meat-space, rather than creating it. Changes are gradual instead
| of instant roll-outs. Patterns change over time and only get
| documented later.
|
| Making the company code prescriptive would require an insane
| amount of discipline that might be more stifling and restrictive
| than it is freeing.
| staticshock wrote:
| Nailed it. I think about prescriptivism / descriptivism in
| terms of these archetypes:
|
| - "Rule followers" think an org will be better off if everyone
| agreed on a set of rules to follow. At the boundaries, they
| will think about establishing new rules to clarify and codify
| new things. Charitably, I'd add that they might remove rules
| that are obsolete, but we all know this is not sufficiently
| true in practice: governments, for example, are much more
| likely to add new rules than to remove old ones.
|
| - "Rule breakers" think that most rules are suggestions. At the
| boundaries, they will see rules other people are needlessly
| bound by, and translate those into strategic openings for
| whatever game they're playing. For better and for worse, start-
| up ecosystems are full of people like this.
|
| Rule followers want to be told what's allowed, while rule
| breakers try to figure out what _should_ be allowed from first
| principles. At the extreme, they tug the world towards
| authoritarianism or towards anarchy.
|
| This is obviously a spectrum, so everyone has both of these
| archetypes in them, albeit in different proportions (e.g. most
| people pay taxes, but almost no one drives the speed limit).
| ClassAndBurn wrote:
| Any non-digital system you describe "as Code" is not a source of
| truth, but a Source of Hope. The code describes the intended
| state, something has to reconcile it with reality.
|
| This is the same as having it in unstructured documents. Which
| means the auditing is still required funny enough.
|
| So yes, this could be done. I'd love to see what run in the CI/CD
| for a change. When someone works on the wrong thing, or breaks
| compliance IRL, how do you backport it into this? "Alice is a
| software engineer, and created this SaaS account with her email
| when the company was founded. The admin email can not be changed
| and she has admin even though another role should control that"
| mikikian wrote:
| Societies across the planet can benefit from "Government as Code"
| for greater transparency and hopefully less corruption, fraud and
| waste.
| snowstorm82 wrote:
| I have started learning cuelang and there was nice webinar style
| video where the GitHub policies where defined as code and
| deployed with terraform. I immediately thought that such thing
| would be very valuable at auditing.
| oftenwrong wrote:
| This is perhaps a bit different, but Fossil supports storing more
| types of written company artifacts in the repo:
|
| >One notable feature of Fossil is that it bundles bug tracking,
| wiki, forum, chat, and technotes with distributed version control
| to give you an all-in-one software project management system.
|
| https://fossil-scm.org/home/doc/trunk/www/whyallinone.md
| bradbeattie wrote:
| The softer approach to this I've implemented in the past is to
| ingest and link up org data (user accounts, groups, projects,
| etc) into one central DB and then provide an audit notifications
| or dashboards to authorized users. Examples: -
| Slack user detected with full access that isn't associated with a
| staff-grouped LDAP account - Group A in System X doesn't
| match the members of Group A in System Y) - Service Z
| provisioned, but their associated customer account is deactivated
|
| These kinds of violations _can_ be automatically synchronized in
| a variety of ways, but I've seen that result in politically
| embarrassing outcomes (e.g. Sensitive user X is fired, their
| Slack account is automatically deactivated, people notice before
| some kind of staff meeting can be held to talk about what's going
| on).
| staticshock wrote:
| The main problem here is that real people operate in fuzzy
| domains. Snapping them into place "with code" won't magically
| resolve the gray areas inherent to the most valuable real
| workflows.
|
| Think about the prized "high agency worker." What makes them
| desirable is the willingness and ability to make well informed,
| unilateral decisions on matters that are likely not yet
| organizationally codified, or codified in a way that is "wrong"
| for the task at hand.
|
| Also, the reason terraform works is because it is _operational_.
| As in, it's actual code that runs. If it was mere documentation,
| it would drift like nobody's business. In order to make
| "organizational code" operational, you would need enforcement (a
| compliance team?) manually keeping the documentation in sync with
| reality in all of the meat and thought spaces where real work
| happens.
|
| The only place where this can plausibly be automated is in
| digital spaces. In fact, I'm surprised the article doesn't go
| there: "organizational code" starts feeling way more plausible as
| definition for AI agents than for real people, specifically
| because agents are operationalized in digital spaces, where
| enforcement can be automated.
| alexhans wrote:
| > Has anyone tried this yet? If not, why not?
|
| Yes (in a minimalistic TDD like way?). [1]
|
| I agree that the company as code can be tested without too much
| risk if you think about as "model your world drawing a circle
| around what you own".
|
| You can be your own auditor constantly so that you pre-answer
| questions you would ask in an audit.
|
| I would advise against the always tempting "we are the everything
| platform" because that rafely scales and makes you a bottleneck.
| You won't be able to keep up. It's easier to model the tribal
| knowledge of your own world knowing where the frontiers are and
| that can even be a forcing function to simplify and reduce
| externalities.
|
| - [1] https://alexhans.github.io/posts/series/evals/automate-
| audit...
|
| Edit: make sure whoever works on it is pain point driven and
| solves things for themselves and then you will build just enough.
| A world that is more programmatic and can tolerate fuzzy
| translations (MCPs/LLMs) and where you can test (evals) the level
| of quality you need can make this cost effective.
| madmax96 wrote:
| This is exactly what model-based systems engineering tools like
| SysML v2 are designed for. Model-based systems engineering aims
| to generate _all_ engineering artifacts from a formal model.
|
| Imagine it -- security policies, infrastructure, etc. all
| codified in a formal model.
|
| - Push-button generation of ISO-27001 documentation.
|
| - Push-button generation of Terraform.
|
| - Push-button generation of SpiceDB policies.
|
| - ...
|
| There is _a lot_ of missing technology, but this is critically
| important because it will help us ensure regulatory compliance at
| far greater speeds in fields like nuclear and automotive. And it
| enables automated reasoning over the models, to make sure you're
| actually doing what you set out to do.
| burakemir wrote:
| The approach described here - model things as graph - can really
| be applied to model any domains.
|
| If you are into this type of modelling, you may find value in
| Mangle, a datalog-based logic programming language and deductive
| database library. You do not need to invent dozens of DSLs but
| can do it all in one. And without all the RDF trouble.
|
| https://github.com/google/mangle
|
| HN discussion https://news.ycombinator.com/item?id=33756800
|
| Talk at REBASE 2025 "From Facts to Theories"
| https://youtu.be/UjOEHSZDBH8?si=qAjnkBQfPKMVaOPW
| 6510 wrote:
| In the future there will be one giant AI on premise with many
| physical bodies made in our own image to micromanage the humans.
| All conversations are monitored, depending on the complexity of
| your query and who you are talking to tokens are deducted from
| your account. A complex double-entry book keeping system divides
| the tokens and quality of the response over the things the
| company should be doing. Things will be neither investor,
| employee nor customer centric but 100% AI centric.
| debois wrote:
| If it doesn't run, it isn't code.
|
| But things that don't run have much less overhead than code: you
| don't need to test then, update them, maintain them, they can't
| really "not work", people will adapt if they don't make sense.
|
| I /love/ this idea, but I don't think it's practical. Documents
| and business practices are about arranging people into semi-
| predictable organizations. The computing units of those
| organizations are people, and people run on text, not code.
| w10-1 wrote:
| Amazon and Koch Industries are are probably the significant
| companies that come closest to this level of description and
| prescription.
|
| You'd need something like probabilistic programming language to
| model discretion.
|
| You'd want some way to compare organizational forms -- minimally
| build vs buy, but preferably also control via
| monitoring+specification vs selection+incentive alignment.
|
| You'd probably need the kind of sensors and telemetry that no one
| would like, to avoid drowning in book-keeping.
|
| Overall, what would the benefit be?
| resonious wrote:
| If you want this to extend to _all_ compliance checkboxes, I
| think it 'd be an endless can of worms.
|
| How do you enforce (with code) that all new applications created
| by various teams get added to the right inventory? At some point
| a human has to determine if an application is in- or out-of-scope
| for certain restrictions.
|
| If a compliance framework requires certain hashing algorithms for
| certain types of data, how does your company-as-code system
| enforce that?
|
| What I see with compliance is that a lot of it is the framework
| saying "you must do X and Y and Z", and the solution is to write
| a document saying "employees must do X and Y and Z" then share it
| with everyone. Then you take a screenshot of that happening (if
| even possible - you might instead just swear that it's
| happening).
|
| I guess what I'm getting at is that there's a huge human element
| here to begin with. If the article is proposing a structured
| language for declaring your company and policies, how is that
| different from a Word doc? That is, unless your structured
| language is actually interpreted by a program that is capable of
| enforcing what it says. And I think building that enforcement
| system would be quite hellish.
| nickdothutton wrote:
| I wrote a little on this same topic, automating away compliance
| with evidence, back in 2018 [1]. Some might find it interesting.
|
| [1] "A Universal Lemma For Compliance"
| https://blog.eutopian.io/a-universal-lemma-for-compliance/
| CatBread wrote:
| I think documentation, in the form of code is the ultimate goal
| for everything. But, the problem of divergence remains. We
| already struggle to keep documentation on codebases (which we
| interact with on a daily) converged with the reality. On the
| business side, it's very difficulty to find the practicality of
| having these relationships documented, as it is a social problem.
| One thing for sure, is that it is hard to document social context
| in an business setting. Like, that one annoying guy that everyone
| avoids. It would be known socially, but these complex
| relationships cannot be written. Either way, I think it would be
| cool to reach this system eventually.
___________________________________________________________________
(page generated 2026-02-05 23:01 UTC)