You don't have to hand-write your openapi.yaml. we are using quarkus, and by annotating the endpoints you get a generated openapi.yaml.
We then use this in a typescript generator to generate client code.
We then use this in a typescript generator to generate client code.
I dont think by doing it this way you really get the benefit of the premise of this article. You get some other benefits, like API documenation and perhaps client code generation and that's perfectly ok if that's all you need.
However, if you believe in the idea of schema-driven, design-first api development, don't do this.
This is what I do. I have typescript functions that generate openapi responses.
I do generate the schémas from sequelize models, blending in descriptions and enums where appropriate.
https://southpole.stoplight.io/docs/calculate/docs/CSV%20imp...
Then we write the code to implement the spec. (We tried using code generators for this step, but quickly dropped them. If your language and web frameworks are sufficiently concise, adapting the generated code to your needs is likely to be more work than just writing from scratch.)
Then we enable an automatic tool to automatically generate an OpenAPI spec from the code. We can then compare it to the original spec to quickly see if we missed something. It's not an automated diff, but it still saves a _ton_ of time.
Finally, we use code generators for the client code. Those actually work pretty well, unlike server-side code generators, probably because there's little room for customisation in making HTTP requests.