As explained below, I don't agree that it's a good idea to replace bureaucracy with code. However, I think the lessons our industry has learned in architecting software systems could inform designing efficient data and request flow within a bureaucracy. At the very least, it gives us language to talk about bureaucracies as systems.
This I definitely agree with; it's kind of disappointing the information systems engineering knowledge has tended to become siloed within organizations dedicated to information technology, because you get much bigger gains if you apply that knowledge to broader processes, not just within computing systems supporting the processes. OTOH, with people who have that knowledge generally getting paid more to apply it in IT (and getting listened to more there), it's kind of understandable if unfortunate that the knowledge gets stuck in IT.
Having spent a fair amount of time working in various bureaucracies, and studying law and government administration, that's very much not true. It's very much the idealized view that many people outside of bureaucracies have of them, especially people in computing, but it's very much not a good approximation of most real bureaucracies, or their governing law and regulation, because the latter usually is written in a way which deliberately relies heavily on discretion within (often deliberately fuzzy) constraints rather than seeking to provide deterministic rules for outcomes, and in many systems regulation is actually written by the bureaucrats enforcing it (who also tend to have disproportionate influence on shaping the actual law).