Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than "working with a team" of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we're all sick of the process and late for delivery of the documentation products.

When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told "do it again in Go" and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.

You missed the documenting the code

Your words.

As for your job title, don't take this badly but "Systems Architect" is not at all the same as "Technical Architect".

If you're actually designing or at least tuning software development processes and coding standards across multiple teams (so, not just optimizing how teams work but also optimizing cross-team work), you're a Technical Architect.

A Systems Architect, when the title is properly used, just means that you're designing software whose operation spreads across multiple platforms (so, for example, multiple tiers in a multi-tier system).

Also there is quite a range in Systems Architect - knowing how to code in two or more platforms (say, STM32 and some Android, to make a bit of home electronics with a microcontroller be controllable from a smartphone) is not at all the same as knowing how to design a high-performance distributed system running in multiple machines, integrated with multiple external system working for ten/hundred of thousands of client front-ends and supporting things like Distribute Transactions so that any failures don't leave half-complete operations.

You can be a Systems Architect and be isolated form most of the concerns of the software development out there. especially if you're a team of one developing the software side of products based on some marketing person's idea of what customers supposedly want.

Unsurprisingly, Technical Architects are non-existent outside large companies and even there they're pretty rare.

Again, still making my point on Dunning-Krugger.