Designing for tomorrow's programming workflows

New tools are changing how people program, and even who programs. Type hints, modern editor support and, more recently, AI-powered tools like GitHub Copilot and ChatGPT are truly transforming our workflows and improving developer productivity. But what does this mean for how we should be writing and designing our APIs and libraries?

In this talk, I'll share what I've learned from developing open-source tools used by thousands of developers, strategies for how to design future-proof developer APIs and why, contrary to what you might think, making tools programmable is becoming even more important, not less.

If how people program is changing, how should we adjust how we’re designing our APIs, whether they’re Python, REST or some other technology? In this talk, I’ll suggest three implications.

First, programmatic interfaces are becoming more accessible. More professional tools can be optionally programmable, and more users will be able to take advantage of that feature to make their tasks more reliable and less repetitive.

Second, libraries can lean more towards composable building blocks, instead of offering a large flat surface of entry point functions. Guiding users through multi-step workflows is hard, so a "horizontal" design with lots of all-in-one functions can be easier to adopt from documentation. But the horizontal design is also harder for users to extend and debug. Generative AI tools can help address the learning curve problem, and give users more control.

Third, backwards compatibility will be more important than ever. Evolving versions already made it much harder to find usage from sites such as StackOverflow, and it causes an even bigger problem for current generative AI technologies. This is another point in favour of composable building blocks, as it's much harder to maintain backwards compatibility for a horizontal API style.

Transcript

1. DESIGNING FOR TOMORROW’S PROGRAMMING WORKFLOWS Matthew Honnibal Explosion
2. 200m+ downloads spacy.io SPACY Open-source library for industrial-strength natural language processing
3. ChatGPT can write spaCy code! 200m+ downloads spacy.io SPACY Open-source library for industrial-strength natural language processing
4. PRODIGY prodigy.ai 800+ companies 9k+ users Modern scriptable annotation tool for machine learning developers
5. PRODIGY Alex Smith Developer Kim Miller Analyst prodigy.ai 800+ companies 9k+ users Modern scriptable annotation tool for machine learning developers
6. PRODIGY TEAMS BETA prodigy.ai/teams Collaborative data development platform
7. PRODIGY TEAMS Alex Smith Developer Kim Miller Analyst GPT-4 API BETA prodigy.ai/teams Collaborative data development platform
8. debugging cloud permissions navigating Linux tools lots more HOW I’M USING CHATGPT
9. AI-POWERED CODE TOOLS
10. 1. Interactive documentation ChatGPT: similar to Stack Overflow or IRC AI-POWERED CODE TOOLS
11. 1. Interactive documentation ChatGPT: similar to Stack Overflow or IRC AI-POWERED CODE TOOLS 2. In-editor support Github Copilot: replaces IDE features
12. 1. Interactive documentation ChatGPT: similar to Stack Overflow or IRC AI-POWERED CODE TOOLS 2. In-editor support Github Copilot: replaces IDE features Generator tools e.g. create tests, still quite young 3.
13. 1. Interactive documentation ChatGPT: similar to Stack Overflow or IRC AI-POWERED CODE TOOLS 2. In-editor support Github Copilot: replaces IDE features Generator tools e.g. create tests, still quite young 3. Just better IDE stu ff especially for Python, via types 4.
14. BACKWARDS COMPATIBILITY MORE IMPORTANT
15. BACKWARDS COMPATIBILITY MORE IMPORTANT • Resources like blog posts and discussion forums are very important. Programmers cannot live on documentation alone.
16. BACKWARDS COMPATIBILITY MORE IMPORTANT • Resources like blog posts and discussion forums are very important. Programmers cannot live on documentation alone. • We all know how much harder it is if the library has had a lot of breaking changes over time.
17. BACKWARDS COMPATIBILITY MORE IMPORTANT • Resources like blog posts and discussion forums are very important. Programmers cannot live on documentation alone. • We all know how much harder it is if the library has had a lot of breaking changes over time. • For LLMs, it’s even harder. The model really can’t keep the di ff erent versions separate.
18. STANDARD DEPENDENCIES MORE IMPORTANT
19. STANDARD DEPENDENCIES • AI tools are much more proficient with popular technologies. Need critical mass of discussion. MORE IMPORTANT
20. STANDARD DEPENDENCIES • AI tools are much more proficient with popular technologies. Need critical mass of discussion. • Should we widen the scope of the standard library? MORE IMPORTANT
21. STANDARD DEPENDENCIES • AI tools are much more proficient with popular technologies. Need critical mass of discussion. • Should we widen the scope of the standard library? • It changes the implement vs. import trade-o ff . MORE IMPORTANT
22. UNIFIED INTERFACE MORE IMPORTANT
23. UNIFIED INTERFACE • Libraries can easily end up with parallel, non-interacting abstractions. MORE IMPORTANT
24. UNIFIED INTERFACE • Libraries can easily end up with parallel, non-interacting abstractions. • This happens when new sugar is introduced, and we don’t want to abandon the old users. MORE IMPORTANT
25. UNIFIED INTERFACE • Libraries can easily end up with parallel, non-interacting abstractions. • This happens when new sugar is introduced, and we don’t want to abandon the old users. • AI struggles with this – as do humans! MORE IMPORTANT
26. UNIFIED INTERFACE • Libraries can easily end up with parallel, non-interacting abstractions. • This happens when new sugar is introduced, and we don’t want to abandon the old users. • AI struggles with this – as do humans! • Maybe bite the bullet and call it a new library? MORE IMPORTANT
27. PUSH-BUTTON SOLUTIONS LESS IMPORTANT
28. PUSH-BUTTON SOLUTIONS • Technologies compete on time-to-first-solution. LESS IMPORTANT
29. PUSH-BUTTON SOLUTIONS • Technologies compete on time-to-first-solution. • Composable building blocks ask users to invest upfront. LESS IMPORTANT
30. PUSH-BUTTON SOLUTIONS • Technologies compete on time-to-first-solution. • Composable building blocks ask users to invest upfront. • Upfront investment is risky. Users want to see payo ff . LESS IMPORTANT
31. PUSH-BUTTON SOLUTIONS • Technologies compete on time-to-first-solution. • Composable building blocks ask users to invest upfront. • Upfront investment is risky. Users want to see payo ff . • Code assistance o ff ers a solution. LESS IMPORTANT
32. LIBRARIES SHOULD SHIP LESS SUGAR
33. LIBRARIES SHOULD SHIP LESS SUGAR • Focus on the core data structures and routines. AI can’t do this for us.
34. LIBRARIES SHOULD SHIP LESS SUGAR • Focus on the core data structures and routines. AI can’t do this for us. • Accept initialization and cleanup steps if that’s the truth of how it works.
35. LIBRARIES SHOULD SHIP LESS SUGAR • Focus on the core data structures and routines. AI can’t do this for us. • Accept initialization and cleanup steps if that’s the truth of how it works. • Smaller user-facing API.
36. LIBRARIES SHOULD SHIP LESS SUGAR • Focus on the core data structures and routines. AI can’t do this for us. • Accept initialization and cleanup steps if that’s the truth of how it works. • Smaller user-facing API. • More IDE extensions, documentation and examples.
37. LIBRARIES SHOULD SHIP LESS SUGAR • Focus on the core data structures and routines. AI can’t do this for us. • Accept initialization and cleanup steps if that’s the truth of how it works. • Smaller user-facing API. • More IDE extensions, documentation and examples. • Use AI and develop AI assistants alongside the library.
38. Flat API spacy.fyi/ltwc “Let Them Write Code”
39. are, going, swimming, should, go Flat API spacy.fyi/ltwc “Let Them Write Code”
40. going, swimming, go Flat API spacy.fyi/ltwc “Let Them Write Code”
41. go, swim, go Flat API spacy.fyi/ltwc “Let Them Write Code”
42. go, swim Flat API spacy.fyi/ltwc “Let Them Write Code”
43. go, swim Deep API spacy.fyi/ltwc “Let Them Write Code”
44. CAN WE SHRINK PRODUCT UI SURFACE, TOO?
45. CAN WE SHRINK PRODUCT UI SURFACE, TOO? • New tools are making programming much more accessible.
46. CAN WE SHRINK PRODUCT UI SURFACE, TOO? • New tools are making programming much more accessible. • Programmatic interfaces are inherently more powerful than UIs.
47. CAN WE SHRINK PRODUCT UI SURFACE, TOO? • New tools are making programming much more accessible. • Programmatic interfaces are inherently more powerful than UIs. • Programmatic interfaces generalize easily over collections.
48. CAN WE SHRINK PRODUCT UI SURFACE, TOO? • New tools are making programming much more accessible. • Programmatic interfaces are inherently more powerful than UIs. • Programmatic interfaces generalize easily over collections. • Programmatic interfaces don’t require repetitive actions.
49. CONCLUSION
50. CONCLUSION •There’s an ongoing struggle between “simple” and “easy”.
51. CONCLUSION •There’s an ongoing struggle between “simple” and “easy”. •“Easy” outcompetes “simple” in the short-term, even if it’s worse in the long-term.
53. 🙏 THE HOPE AI tooling makes simple easier.
54. 🙏 THE HOPE AI tooling makes simple easier. 🤔 THE UNKNOWN How do we build AI support for new technologies?
55. 🙏 THE HOPE AI tooling makes simple easier. 🤔 THE UNKNOWN How do we build AI support for new technologies? 💖 THE GOOD FUTURE We get higher quality tools and use AI to help with the glue.
56. 🙏 THE HOPE AI tooling makes simple easier. 🤔 THE UNKNOWN How do we build AI support for new technologies? 💖 THE GOOD FUTURE We get higher quality tools and use AI to help with the glue. ☠ THE BAD FUTURE Language models poison the web and kill discussion sites, giving the libraries of today a big incumbency advantage.
57. THANK YOU! LinkedIn Explosion spaCy Prodigy Twitter Mastodon Bluesky explosion.ai spacy.io prodigy.ai @honnibal @honnibal@sigmoid.social @honnibal.bsky.social