4 ms·

Even if copilot could manage the things you fear it can (it can't) then you just move the post one bar further. Now you need people that can describe software i

• deleted 4y ago
  [deleted]
• webmaven 4y ago
  > Even if copilot could manage the things you fear it can (it can't) then you just move the post one bar further. Now you need people that can describe software in terms copilot (or DALL-E or GPT3 or whichever new software we make next) can build something useful from. I'm getting a bunch of contradictory vibes. Office Space "I have people skills!" vibes. Executives having their secretary print out their email vibes. "4GLs will put programmers out of work" vibes. Here are a couple of questions that are currently unanswered: Will copilot-like tools increase or decrease the pace of library and framework and API and platform development and proliferation? Who determines what capabilities are changed, added, and deprecated in these dependencies? Who decides which libraries and frameworks and APIs and platforms to use in an app? Who decides that some dependency has to be changed (not to a new version, but to some other implementation)? Do we get more smaller dependencies, or fewer, larger ones? Do we get more composition of dependencies, or more inheritance (ie. transitive ones)? When a dependency gets a new feature, who recognizes the possibilities it opens up? When a bug in an app is traced back to a dependency, who reports the issue or pushes a fix upstream? In a co-pilot driven future, does more of the software development ecosystem come to resemble front-end development in terms of churn, or the other way around?