It is, but most developers I know (including myself), spend more time in meetings talking about what the tool should be except in the concrete details that would allow any of us to craft the tool while never actually getting around to making it. Occasionally, we'll spend time criticizing broken tools that someone made in ways that let us feel like we're getting better at making non-defective tools.
However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.
Pretty much all of programming is constant toolmaking, usually much more abstract and sophisticated than anything in the article. Every subroutine, utility function, library, and interface, for example.
However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.