Devin, the First AI Software Engineer

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • chatgpt-shell

    ChatGPT and DALL-E Emacs shells + Org babel 🦄 + a shell maker for other providers

    I think it is a tooling issue. It is in no way obvious how use LLM's effectively, especially for really good writing results. Tweaking and tinkering can be time consuming indeed, but i use lately the chatgpt-shell [1] and it lends well to an iterative approach. One needs to cycle through some styles first, and then decide how to most effectively prompt for better results.

    [1]https://github.com/xenodium/chatgpt-shell/blob/bf2d12ed2ed60...

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • Node RED

    Low-code programming for event-driven applications

    Good question.

    I expect that we're moving into a phase of AIs talking to AIs, and initially it'll be wasteful (because it'll be mostly English), but eventually, they'll derive their own language and seamlessly upgrade protocols when they determine they're talking to an AI. No clue how that will come about or what that language will look like, but honestly, it's kind of exciting.

    Really interesting to think about how they might handle context, as well. Even though we have much bigger context windows (and they'll only get larger), context management is still a resource-management issue, which we'll probably continue to refine, as well. Imagine different strategies for managing both what is brought into the context of each request, as well as what form it could take (level of detail, additional references or commentary on it, etc). Things could get really unreadable even in English, and still be very interpretable for an LLM.

    W.r.t. the graph-oriented interfaces, are you thinking something like Node-RED [1]? I'm seeing more and more people mention having LLMs produce non-text or structured outputs, like JSON, UI, and other things. Easy to imagine an LLM that wires together various open-source platforms, on-demand. Something like Node-RED for pipelines/functions, some UI tools for visualization/interactivity, other platforms for messaging, etc...

    [1] https://nodered.org/

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Node-RED: Low-code programming for event-driven applications

    1 project | news.ycombinator.com | 23 Dec 2023
  • Open source IPaaS With Drag and Drop integration

    1 project | /r/opensource | 7 Dec 2023
  • #OpenSourceDiscovery 84 - Node-RED, alternative to IFTTT or Zapier, a workflow automation tool

    1 project | /r/opensource | 22 Nov 2023
  • Low-code programming for event-driven applications

    1 project | news.ycombinator.com | 13 Sep 2023
  • Loops and conditional branching (IF then else) in ComfyUI?

    1 project | /r/comfyui | 20 Aug 2023