111–120 of 259 posts
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck. It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it. It's why execs always talk about not getting too far away from the work. It's how seagull management happens. It's why program ma…
ie. understanding it AFTER it’s already generated rather than before you wrote the code by hand
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck. It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it. It's why execs always talk about not getting too far away from the work. It's how seagull management happens. It's why program ma…
While I agree at face value, I also believe a lot of managers and PMs do not have enough work to justify 40 or more hours of work a week, so attending standup, meetings, etc. is performative attempt at self-preservation.
Of course, there are many managers and PMs that are leading death marches, so I know it's highly workplace dependent.
I've been having a good time with Spec Driven Development, and it directly addresses the issue of needing the understand. The whole idea is that you specify exactly what you want in some SPEC.md file. You can of course nest them, have multiple, etc, but the core idea is that the SPEC file is the source of truth, and all the code should be able to be generated by a competent agent into the working product you want. Th…
When that happens, do you read just the spec, or do you also need to read the code? Is there a difference between "I can remember what I intended" and "I can predict what the system will do in a situation the spec didn't cover"?
Interestingly, you said the spec author must be you. What happens when you join a codebase where someone else wrote the SPEC, or where an agent wrote the code and nobody spec'd it? Is the spec still sufficient, or does the "you must write it" part mean the understanding doesn't transfer?
I've been having a good time with Spec Driven Development, and it directly addresses the issue of needing the understand. The whole idea is that you specify exactly what you want in some SPEC.md file. You can of course nest them, have multiple, etc, but the core idea is that the SPEC file is the source of truth, and all the code should be able to be generated by a competent agent into the working product you want. Th…
same, I've been liking https://openspec.dev/ and find the more time I put iterating/scrutinizing the spec artifacts (proposal, requirements, design, tasks) before I let the agent implement the better understanding I have and the better results I get. Also like that it is agent agnostic so I can take it with me as I try different agents/models.
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck. It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it. It's why execs always talk about not getting too far away from the work. It's how seagull management happens. It's why program ma…
As a manager, the first thing you do is get to know your people. Some of them will be very strong and trustworthy. You give them the hardest work, and you ask them the least. That’s how you scale your team’s scope without getting overburdened. And that’s why teams have key people.
But when you work with LLMs, you still need to understand most of the ideas yourself if it’s a serious product. Because in the end, it means nothing to “trust” an agent. You’re the one responsible for what you and the LLM ship.
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck. It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it. It's why execs always talk about not getting too far away from the work. It's how seagull management happens. It's why program ma…
[flagged]
I've been having a good time with Spec Driven Development, and it directly addresses the issue of needing the understand. The whole idea is that you specify exactly what you want in some SPEC.md file. You can of course nest them, have multiple, etc, but the core idea is that the SPEC file is the source of truth, and all the code should be able to be generated by a competent agent into the working product you want. Th…
Earlier quoted context omitted.
I hate to be pedantic but you can finetune a skill to shape the PR message the way you like it. That being said, I did have exactly this issue you mentioned, but the defualt output can always be tuned.
I don't know why you got downvoted, but I find myself wanting to say some version of what you just said over and over again. People write extremely lazy, straightforward prompts and expect the LLM's intelligence to take care of all of it. But the reality is that you need to actually put some thought and effort into your prompts and provide appropriate context and examples a lot of the times if you have a very specifi…
Ain't gonna happen. By that point in time, I might as well do it myself. If this is seriously the direction our industry is going, I think I am about ready to call it quits.