I think that this idea has some upsides:
Le'ts run through them one by one.
tests are written by someone, who can see more about the implementation,
So, you mean that the first developer has spent time writing some implementation, which he is not sure works. Then, another developer comes and writes tests, basing his reasoning on code nobody knows whether it's correct, and hoping that it brings a tactical advantage compared to writing tests only with regards to what the code is supposed to do. If the implementation is incorrect, my opinion will be it brings zero help towards writing tests.
work should be made little faster than pair programming (two features at the same time)
Once both developers have finished their initial development, nobody knows whether either of their code is correct. This still remains to be checked, nobody can tick off any one as done, and nobody can predict when they will be done. Compare this to TDD: You write the test first, then make the test fail, then pass with code. That's code supporting more and more scenarios. That's forward motion.
If you make them progress in parallel, code that could be reused in both features will be written twice, and cost twice more.
both tests and code has responsible person for it,
Look into collective code ownership, as proposed by XP. You will have even more people responsible for the code. If your goal is to share knowledge between developers, why are you trying to segregate them?
code is tested by at least two people
With pair TDD too. When pairing, both people have to agree that written code is adequate or not write it. If that results in a fight, some people in the team have a misplaced ego problem.
maybe searching for errors in code written by person that is testing your code would give special motivation for writing better code and avoiding cutting corners.
Searching for errors implies that at some point, you tolerated that they get in. If they got in, they were unnoticed. Refusing to write tests first is giving licence to errors to get in.
Cutting corner may be unintentional. That's what pair programming is for. Each member of the pair should be instructed with the duty of not letting the other one cut corners, because well, we all do that. That requires leaving your pride in the closet and take it back when you leave office. If you expect your people to be unfailingly rigorous, you're not considering the common situation and set yourself up for failure.
XP says explicitly that all practices XP is made of reinforce each other by covering each other's defects. You should not listen to criticism of any practice of XP separated from the others. No one practice is perfect, TDD is not perfect, pair programming is not perfect, collective code ownership is not perfect, but they all cover for each other.
assert true
as tests and call it a day because every test was passing. One important step was missing : the tests should fail first, and should be made to pass by changing the code, not the tests.