One thing you might try is to have the "fluffy" developers break each issue (what in Jira would be a Story or Task) into subtasks.

These can be actual Jira Subtasks or just bullet-pointed steps in the issue description that document what needs doing and what that will require.

Thinking through and breaking down work this way can lead to more accurate estimation as well as making it easier to see progress. If a developer isn't "check off" subtasks (or revising the list of subtasks), s/he isn't making progress.

Try to see this as a growth process, if possible. Some developers are open to it, will see it as an opportunity to improve, and will almost immediately see benefits. Others will resist on the grounds that it's "a lot of words", looks hard, takes too long, etc. You need to be prepared with data that shows the amount of re-work needed currently and an accurate accounting of the true cost of inexact requirements.

There might also be a problem with level of specificity of the issue itself.

If interested, you can read a short article I've written about how to write More Effective User Stories with an example on my site at https://cygnustechnologyservices.com/services/services-more-effective-user-stories/.

I hope you find it helpful and would appreciate your feedback, questions, suggestions for improvement, etc.

I've found that using Gherkin syntax as shown in the example, including unsuccessful (or "sad") path as well has successful (or "happy") path scenarios, and providing objectively verifiable acceptance criteria make a huge difference in clarity for those who do the work as well as those who manage the process.