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.

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.

squaresinger's point matches what I've found. Once three agents are going, you become the coordination point - you're holding the plan and reviewing all of it, and that part doesn't scale the way the generating does. What's kept it manageable for me is treating each one like an intern on a single, well-specified task I can check before it moves on, rather than running a swarm and hoping it converges. Wrote this up here: https://prickles.org/tenet/the-intern-pattern/AI1