I've used spec-kit and also rolled my own lighter version of the same idea. The framework matters less than the habit it forces, which is writing down what 'done' looks like before the agent starts. When I just prompt without that, I get something plausible that I then argue with for an hour. When the spec has acceptance criteria the agent can check itself against, most of that back-and-forth goes away. The caveat is that spec-kit can be heavier than a small change needs, so for quick work I'll write the criteria in a comment and skip the ceremony. Worth trying. For me the habit of writing the criteria first is what stuck, more than the tooling around it.
The networking advice is right, but here's the part you can actually control while you wait for that to pay off. Most fresh-grad applications look the same from the other side of the desk, a degree and a list of tutorials. What made me put someone through to interview was evidence of judgment: one or two small projects that are genuinely finished, with tests and a readme, ideally deployed somewhere I can poke at. Not a half-built clone of something. And in the cover note, one specific trade-off you made and why you made it. That reads as someone who has actually shipped, which is rarer than it should be.