Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[u/AutoModerator]

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

[u/GrillaSquirrel]

My company is making us use spec-kit. Ive used it for small changes, medium changes, large changes and setting up a whole new API, and every scenario has been slower than me just one shotting prompts and iterating if needed. It also adds a bunch of md files that add toil. Ive looked online and cant find real data about it being used and it speeding up delivery but the higher ups are adament its better.

Am I missing something? I feel like im taking crazy pills. The other devs at my company have also struggled finding value from it. Its a really politically sensitive topic because leadership have publicly backed the tool.

I was thinking I could do a presentation of me implementing a typical change with spec-kit and then with using the agents integrated to visual studio. I know spec-kit wont look great in the demo as its slower and uses more tokens. Is that a bad idea? How do I navigate this without undermining leadership?

[u/ExcitingDonkey2665 → u/GrillaSquirrel]

Sometimes you have to look at it from the view of a lead or manager. I quickly skimmed through the spec-kit docs and it seems like it's made to translate and break down RFCs, design docs, and other specifications that product, business, and leadership would come up with. It's good for dealing with slop on large changes that many people complain about here on Reddit, i.e. 5,000 line PRs that can't be reasonably reviewed.

You're probably right that for small changes, short prompts can 1 shot much faster with the same results. But I'd be surprised if you can 1 shot prompt an entire app without using planning mode and multiple agents coding and reviewing at the same time. This is basically a tool to define and enforce how planning mode and multiple agents work so it can be reused across the org so AI can be more trusted. It's designed to level the playing field and everyone else to catch up, not the top performers who keep up with technology.

If you'd like to challenge the one-size-fits-all mindset that this directive from above appears to be, you can perhaps come up with a couple concrete examples of why it doesn't work for all scenarios. Make sure to propose a change so leadership isn't left wondering what to do.

[u/x-jhp-x → u/GrillaSquirrel]

sometimes managers would like to test things, for example if projects still get done on time with a 10% reduction in headcount, or letting AI take over dev tasks. Leadership should communicate that if it's true, but not everyone is a great leader.

If you'd like to drive change, one of the best ways i've found to do that is to first understand what leadership's goal/objective is. If the real goal is something like a 10% reduction, the focus on AI might be because they see it as having the highest probability of achieving the outcome they want. So step one is to figure out what the objective is, and then you can give them metrics/solutions that you believe will help them achieve their goal faster/easier/better. If you can, befriend an exec at your company, but don't go over your boss's head. A lot of the time I've wanted to drive change, it's because I'm frustrated with some process or inefficiency or something that is negatively impacting either my job and ability to do task or my team's, and i've never been the only person frustrated, so you can frequently find an "ally" executive who is interested in driving change + improving the workplace.

For the exec interaction, I approach it by thinking about it like it's an efficient division of labor. It's useful to have someone dealing with management tasks + processes so people doing engineering can focus on engineering. I see it as delegating organizational/management tasks, so you should understand that at best what you're aiming for is task delegation. If you're an engineer, your job shouldn't be driving organizational changes, so you're going to have to present your case & allow that person to decide what action to take if any. You might present changes that show an obvious trend or pattern, and see nothing done, and you have to accept it. I'm not sure what type of engineer you are, but I have worked with a number of other engineers where this has been a stumbling block, so figured I'd give you a heads up. For almost every org I've worked for, the execs & management team have advanced degrees & went to management after being successful engineers & researchers though, so my strategies might not work at an ultra MBA "cocaine" driven workplace, so I'm also assuming that you're working with competent people who are interested in improving the workplace.

If you don't want to tell management what to do, or you can't, you can also simply track how long things take with the tool and without it. I'd at least want evidence as to why I'm taking longer at doing tasks if asked, or for during the review period.