> The engineers who've adopted these tools effectively get heard more often, get their proposals taken seriously more often, and shape direction more than those who haven't.
I want to point out if the organizational model or your team's engineers are resistant to change, it doesn't matter how good of an engineer you are, or how good at proposal writing you are. With or without AI.
> Instead there’ll be a much stronger focus on teams of generalists, or combined teams of specialists from different fields, working on a feature or product end to end.
> Coordination has in my experience always been the big bottleneck in getting anything done
I work at a large enterprise you've heard of. They're currently re-organizing the product area to remove currently-static two pizza teams into an amorphous blob of feature-oriented teams. Once the feature is complete, the team is dissolved and the engineers re-enter the pool, tasked with new features.
All that to say, I think you're right on the money with your assessment.
This is a great strategy idea, I like it. I'm not good at thinking out the curse of the monkey's paw, so I'm curious if folks can think of any downsides.
Exactly this. So far it's helped identify blind spots in my thinking, as well as educate me further on the techniques and frameworks I'm already using. It's been tremendously helpful at developing very well thought out _and tested_ software.
> Open Source and the OSI are an industry plant. Look at who sponsors it.
This is ignorant to the history of Open Source software. Software has been open long before it was subsidized by large corporations.
"Computer software was created in the early half of the 20th century.[2][3][4] In the 1950s and into the 1960s, almost all softwares were produced by academics and corporate researchers working in collaboration,[5] often shared as public-domain software." https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...
Unfortunately that's not the case. There are many senior and above level engineers out there who are unskilled communicators but very technically skilled.
Indeed, I'm not using LLM output without thorough review.
After reading a bunch of other comments, it sounds like people are referring to letting agents go wild and code whatever off a limited prompt. I'm not using LLMs like that; I'm generally interacting only via conversations with pretty detailed initial prompts. My interactions with the chat after that are corrections/guiding prompts to keep it on point and edit the prompt output from time to time.
Yeah, their statement just isn't true. With enough instruction, I've been able to get great output from models. I think that's the key: with detailed, pointed instructions, the output will match.
You realize _anytime_ someone needs to talk to you would qualify as interrupting and bothering someone else? Your expectation is unreasonable. Good luck with that.
This is 100% completely on you, then. If you don't inform people you're being interrupted or that what they are doing is bothering you, they have no data to telling them to stop, and any energy you spend on silently judging them or being frustrated is only harming yourself.
That's literally what the world is. It's the amusement park for all of us. Some of us like sharing our joy with others. It's up to you whether you are open to receiving it.
This doesn't affect day to day operations for the vast majority of users, though. Unless you're these guys (and maybe Pulumi and a handful of others), one's ability to use Terraform as the way you manage your cloud infrastructure is unaffected.
...quoted from the co-founders of a closed-source company running previously open-source software. Pot calling the kettle black. Their company wouldn't exist either, this is a ridiculous statement.