On the heels of the "LLMs and the future of progra...
# thinking-together
j
On the heels of the "LLMs and the future of programming" discussion (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1679642239661619, https://futureofcoding.slack.com/archives/C5T9GPWFL/p1679892669316079), I'd like to start a more concentrated discussion around their effect on Future of Coding projects. There was already some sentiment that LLMs are going to kill FoC projects. Some yes, but certainly not all. So what kind of FoC projects LLMs will not kill?
To kick off the discussion I did the only logical thing and asked ChatGPT. _what are the strengths of low-code and no-code tools against programming with the help of an LLM?_:
Low-code and no-code tools, as well as Language Models (LLMs) like GPT-4, each have their own strengths in software development. Here, we will focus on the strengths of low-code and no-code tools when compared to programming with the help of an LLM.
1.
Accessibility: Low-code and no-code platforms are designed to be accessible to non-technical users, enabling more people to create software applications without needing extensive programming knowledge. LLMs, while powerful, still require a basic understanding of programming concepts to be used effectively.
2.
Visual Interface: Low-code and no-code tools often provide a visual, drag-and-drop interface, making it easy to design applications and see the structure of the application. This can be more intuitive than using an LLM, which generally requires text-based communication and code editing.
3.
Standardization: Low-code and no-code platforms typically enforce standardized coding practices and patterns, which can result in more maintainable and organized code. On the other hand, LLMs might generate code with different styles and conventions depending on the input.
4.
Integration: Low-code and no-code platforms often provide pre-built integrations with popular services, databases, and APIs. While LLMs can also help generate code to interact with various services, they might require more manual work to integrate and configure the connections.
5.
Speed of Development: Low-code and no-code tools can significantly speed up the development process, as they automate repetitive tasks and allow users to focus on the overall application design. LLMs can also speed up development, but the improvement might not be as dramatic, especially for simpler applications.
6.
Collaboration: Low-code and no-code platforms often have built-in collaboration features, allowing multiple team members to work on the same project simultaneously. While it's possible to collaborate using LLMs, it might not be as streamlined as using dedicated low-code/no-code tools.
7.
Predictability: Low-code and no-code platforms provide a more predictable development environment, as they consist of predefined components and actions. LLMs can sometimes generate unexpected or inconsistent code, depending on the input and training data.
While low-code and no-code tools have these strengths, it's important to remember that they also have limitations, such as less flexibility in terms of customization, and potential issues with scaling or performance. The choice between using low-code/no-code tools and an LLM depends on the specific project requirements, the technical expertise of the team, and the desired level of customization.
How about if we expand the scope to the whole process of software development
Expanding the scope to the entire software development process allows us to compare low-code/no-code tools and LLMs across various aspects of the development lifecycle. The following comparison highlights the strengths of low-code/no-code tools in the broader context of software development.
1.
Requirement gathering and prototyping: Low-code/no-code platforms excel at quickly creating prototypes and mockups, which can help in gathering and refining requirements. LLMs can be used for generating code snippets, but they might not provide a complete solution for creating interactive prototypes.
2.
Development and implementation: Low-code/no-code tools can speed up the development process by automating repetitive tasks and providing pre-built components. However, they may lack the flexibility needed for highly customized or complex applications. LLMs can help generate code, but developers still need to manage the overall application structure and logic.
3.
Testing: Low-code/no-code platforms often include built-in testing tools or features, making it easy to validate the application's functionality. While LLMs can help generate test cases or test code, they are not a complete solution for software testing.
4.
Deployment and maintenance: Low-code/no-code platforms usually have straightforward deployment and maintenance processes, often with built-in support for continuous integration and delivery. LLMs can help automate parts of the deployment process, but developers still need to manage the overall infrastructure and maintenance.
5.
Documentation: Low-code/no-code tools often automatically generate documentation based on the application's structure and components. LLMs can be used to generate code comments or external documentation, but they might require more manual effort to ensure that the documentation is accurate and comprehensive.
6.
Collaboration and project management: Low-code/no-code platforms often include collaboration and project management features, allowing teams to work together more efficiently. While LLMs can be used in a collaborative context, they may not provide the same level of support for project management.
7.
Training and onboarding: Low-code/no-code tools generally have a lower learning curve, enabling new team members to become productive more quickly. LLMs can be helpful for generating code samples or answering programming-related questions, but they might not be as effective for onboarding new developers who are not familiar with programming concepts.
While low-code and no-code tools have these strengths in the software development process, they also have limitations. For example, they might not be suitable for highly customized applications or for situations where performance is critical. Moreover, they might result in vendor lock-in, which can limit flexibility and long-term scalability.
Ultimately, the choice between using low-code/no-code tools and an LLM depends on the specific project requirements, the technical expertise of the team, and the desired level of customization and flexibility. In some cases, a combination of low-code/no-code tools and LLMs might be the most effective approach to software development.
so, if I'm working on a low-code/no-code tool and I'm worried that LLMs will make the tool obsolete or significantly decrease it's market potential, what should I concentrate on?
If you're working on a low-code/no-code tool and concerned about the impact of LLMs on your market potential, you should focus on several aspects that can help differentiate your product and provide value to users beyond what an LLM can offer:
1.
User Experience: Create a user-friendly, intuitive, and visually appealing interface that makes it easy for users to build applications without prior programming knowledge. This will help your tool stand out from LLM-based solutions, which often require more programming expertise to use effectively.
2.
Integrations and Ecosystem: Offer seamless integrations with popular third-party services, databases, and APIs. By providing a rich ecosystem of pre-built connectors and integrations, you can save users time and effort, making your tool more attractive than working with LLMs alone.
3.
Collaboration Features: Build in features that facilitate collaboration and communication among team members, making it easier for them to work together on projects. This can provide a significant advantage over LLMs, which may not inherently support collaborative development.
4.
Customization and Extensibility: While low-code/no-code tools are often associated with less flexibility, you can differentiate your product by offering customization options and extensibility features that cater to various use cases and industries. This could include allowing users to create custom components, use scripting languages, or integrate with external code.
5.
Education and Support: Provide comprehensive documentation, tutorials, and support to help users get the most out of your tool. By offering exceptional customer service and resources, you can create a loyal user base and distinguish your product from LLM-based solutions.
6.
Performance and Scalability: Focus on optimizing your platform for performance and scalability, ensuring that it can handle the demands of larger and more complex applications. This will help attract users who require high-performance solutions that might not be achievable with LLM-generated code.
7.
Security and Compliance: Address security and compliance concerns by incorporating features that ensure data privacy, secure user authentication, and adherence to industry-specific regulations. This can be an essential differentiator for customers in regulated industries.
8.
Target Niche Markets: Identify specific industries or use cases where your low-code/no-code tool can provide unique value, and tailor your features and marketing efforts towards those niches. By becoming a specialized solution, you can carve out a market segment less affected by LLMs.
9.
Community Building: Foster a community around your low-code/no-code tool, encouraging users to share their experiences, tips, and best practices. A strong community can help drive user adoption and increase your product's visibility.
By focusing on these aspects, you can create a competitive low-code/no-code tool that offers value beyond what an LLM can provide, ensuring that your product remains relevant and successful in the market.
I would like to add that programming using LLMs still suffers from all of the possible pain points of the chosen programming language, beyond the act of writing code. Such as debugging experience and compilation or deployment times. This is where live programming tools excel for example. Of course, some of the LLM weaknesses will be fixed. Which ones will be fixed first? Which ones last or never? Are there niches (user groups, industries or domains) in which the strengths of LLMs don't apply or are decreased? Are there domains in which LLMs can't/will not be utilized for some (political, financial, social, security, emotional, ..) reason?
n
The points that ChatGPT produced above are quite reasonable. However, the comparison being made is between: ā€¢ Low-code/no-code tools ā€¢ LLMs that generate code in traditional programming languages (e.g. Python code) Many of the listed benefits of no-code tools can be hypothetically be achieved through conventional language design as well. For example, the "opportunities for FoC researchers" that I listed in my previous #thinking-together post focus on how to make LLM-generated code easier to understand, accessible to a wider audience, and less error-prone. Those qualities (amongst others) are major selling points of low-code/no-code tools. My contention is that we ā€” as FoC researchers ā€” can develop new general-purpose programming languages that continue to close the gap between no-code and code while embracing LLMs as a valuable tool in our tool belt.
j
Very good points. Yes, certainly there are other FoC projects than low-code/no-code tools and I'm very interested in involving them in this discussion. I just happened to phrase the prompts like that.. Validation is certainly a good aspect to focus on. LLMs can help with validation as well, but the question is whose validation do we trust. It will be a long road to build the trust even after LLMs have the capability to (never?) make mistakes and somehow always understand our intent from ambiguous natural language.. However, the level of validation we currently require for purely human written code varies case by case. I guess it must be the same for AI written code. For a hobby game project you might be fine if the AI generated game just appears to work, for a medical/military/aviation device not so much. So I think that if efficiency of validation is the competitive advantage your FoC project relies on, make sure that your project targets domains in which correctness is important.
In one of these LLM threads someone wrote about the room for improvement in some interface (text interface?) and felt confident working on that problem regardless the onslaught of LLMs. I can't find the message anymore, but if someone could point the person this way, I would love to hear more šŸ™‚