Are you proposing some kind of quick and dirty solution, but instead of rectifying it at the end ("why? it kinda works!"), just write tests?

As already commented, I do not see anything about abstractions here, so I do not quite see the point, but unless you are really into throw-away prototypes, not thinking about abstractions in the problem domain, is a waste of time. I do not know why this approach is easier to you, but for me it's much easier to understand the task at hand in it's connections with the rest of the system and find proper abstractions in the problem domain, including precise terminology.

And I do not care that much about using / thinking about patterns after that as code just snaps into place not only for the specific task, but also for the surrounding code.

However, my point is thinking about adequate abstractions pays off big time. The resulting code is just natural and it flows smoothly. Finding abstractions (in my sense, not design patterns) is much better way to find requirements as well. They are clearly visible as omissions.