I totally agree with you that the challenges with regard to existing legislation are different, and the opportunities involving encoding in the drafting phase are different.
But I don’t think the differences are material to my argument. A policy person and a legislative drafter aren’t going to need a programmer (in the future) in order to bring that helpful perspective to bear. It will be a part of the drafter’s competency.
They will need better tools than are available today, and to learn new skills. But they will want those tools and skills, because they will make for better drafting, whether the law is ever automated or not, for all the reasons that the Rules as Code conversation has recognized.
You say that you are not well-suited to the task. I disagree. You are ideally suited to the task, and it will be done better and more efficiently by you alone than by you and a programmer. But no one has given you the tools you need in order to make acquiring that expertise realistic.
If we are talking about different things, I would say it is because you are talking about now, and I am talking about the future. The Rules as Code people have got it right. I am not critiquing the idea of involving programmers in the drafting of new legislation OR the encoding of existing legislation right now, because there are no alternatives.
But the technology for this has existed for nearly 40 years. Kowalski encoded the BNA in 1986. The experiments didn’t “take”. There is reason to believe it was because of the knowledge acquisition bottleneck. And there are things we can do to avoid falling into the same trap. So let’s do what we can now, to prove the value. AND let’s improve the tools so that in the future that value is more efficiently captured, and the project doesn’t fizzle out.