4 ms·

As someone who works in this space (https://pythagora.ai https://pythagora.ai), I welcome new entrants to this niche. Currently, mainstream AI usage in coding

by senko 3y ago

As someone who works in this space (https://pythagora.ai https://pythagora.ai), I welcome new entrants to this niche. Currently, mainstream AI usage in coding is at the level of assistants and glorified autocomplete. Which is great (I use GitHub Copilot daily), but for us working in the space it's obvious that the impact will be much larger. Besides us (Pythagora), there's also Sweep (mentioned by others in the comments) and GPT Engineer who are tackling the same problem, I believe each with a slightly different angle. Our thesis is that human in the loop is key. In coding, you can think of LLMs as a very eager junior developer who can easily read StackOverflow but doesn't really think twice before jumping to implementation. With guidance (a LOT in terms of internal prompts, and some by human) it can achieve spectacular results.

jprete 3y ago
While you sound reasonable, I can't tell the difference between an honest opinion and a sales pitch here.
- senko 3y ago
  I am making a sales pitch on behalf of all the projects I mentioned (not just the one I'm involved with). I see LLMs failing at coding daily (one of the "perks" of working in the space), and I'm incredibly bullish on this approach. And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just another iteration of it. (if you do want a sales pitch, here's one: https://twitter.com/senkorasic/status/1765769482985722267 https://twitter.com/senkorasic/status/1765769482985722267 )
  - starbugs 3y ago
    > And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just another iteration of it. Assembler replacing direct machine coding or C replacing assembler was a new higher level ruleset replacing an existing lower level ruleset. But that change was largely static, meaning that you could learn a concept of a mapping of C syntax -> generated assembler and rely on it being predictive of the outcome of your program with relative ease. This is what enabled you to "forget about" assembler and move on with C only. With libraries and frameworks, we introduced another level of abstraction that introduced an element of dynamism since the underlying framework could change at any time. This caused a lot of frustration with many developers already. Now, with AI, another layer of dynamism and an additional layer of "lack of precision" is introduced. What the machine figures out as a solution may change in each run, the AI itself may change, the libraries, frameworks and programming language that it uses may change - all at the same time. This raises the question how any human being should afford the time to train themselves in all the underlying components and the AI so as to be a meaningful expert in the field. Given the speed of development in the AI field, this seems like a losing proposition for anyone to invest their time in. Much different from the direct machine coding to assembler analogy that you mentioned initially.
ukuina 3y ago
Pythagora and similar frameworks are cool and very useful in the short term, but... Large-context models obviate the need for RAG and callgraph-augented generation. Why would would Agents need multiple turns and a framework like Pythagora in a (near-future) world with GPT4-level of capability and 10M+ token context?
- senko 3y ago
  The problem is not (only) the context size, it's (for lack of a better word) focus. GPT4 can easily get lost in too much information and produce results that don't work well (duplicate code or just incoherently solving a problem), and it needs a lot of handholding. Imagine GPT4 (or any other LLM) as a very eager but not very bright junior developer that just started to work with you. It's good, but it'll need a lot of situational management for it to not go wildly off the track. What improved models will bring us in the future is making Pythagora and other such tools work better for large and more complex projects. The tipping point will come when for example you'll be able to load Pythagora in Pythagora and continue development. While we do build some auxiliary/external tools with Pythagora, the core is still handcrafted mostly by a human, and I'm pretty sure that's the case with other code gen tools as well.
- nsokolsky 3y ago
  I've gotten access to Gemini 1.5 Pro today with a (supposedly) 1M context window and unfortunately in practice it's not good at complicated queries over such a large window, involving multiple recursive lookups back and forth.
- hackerlight 3y ago
  > Why would would Agents need multiple turns Because it's better. This was the insight behind AlphaGo, AlphaCode and AlphaGeometry. In Go, trying to get the entire solution in one forward pass required a 1000x larger neural net to achieve the same performance according to Noam Brown. Intelligence requires iteration, introspection, planning, sub-task breakdown, and trial and error with feedback from reality (error messages, print statements). These meta reasoning structures (whether hard-coded or, ideally, learned) will move LLMs closer to how humans reason.

by senko 3y ago

jprete 3y ago

While you sound reasonable, I can't tell the difference between an honest opinion and a sales pitch here.

senko 3y ago
I am making a sales pitch on behalf of all the projects I mentioned (not just the one I'm involved with). I see LLMs failing at coding daily (one of the "perks" of working in the space), and I'm incredibly bullish on this approach. And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just another iteration of it. (if you do want a sales pitch, here's one: https://twitter.com/senkorasic/status/1765769482985722267 https://twitter.com/senkorasic/status/1765769482985722267 )
- starbugs 3y ago
  > And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just another iteration of it. Assembler replacing direct machine coding or C replacing assembler was a new higher level ruleset replacing an existing lower level ruleset. But that change was largely static, meaning that you could learn a concept of a mapping of C syntax -> generated assembler and rely on it being predictive of the outcome of your program with relative ease. This is what enabled you to "forget about" assembler and move on with C only. With libraries and frameworks, we introduced another level of abstraction that introduced an element of dynamism since the underlying framework could change at any time. This caused a lot of frustration with many developers already. Now, with AI, another layer of dynamism and an additional layer of "lack of precision" is introduced. What the machine figures out as a solution may change in each run, the AI itself may change, the libraries, frameworks and programming language that it uses may change - all at the same time. This raises the question how any human being should afford the time to train themselves in all the underlying components and the AI so as to be a meaningful expert in the field. Given the speed of development in the AI field, this seems like a losing proposition for anyone to invest their time in. Much different from the direct machine coding to assembler analogy that you mentioned initially.

ukuina 3y ago

Pythagora and similar frameworks are cool and very useful in the short term, but... Large-context models obviate the need for RAG and callgraph-augented generation. Why would would Agents need multiple turns and a framework like Pythagora in a (near-future) world with GPT4-level of capability and 10M+ token context?

senko 3y ago
The problem is not (only) the context size, it's (for lack of a better word) focus. GPT4 can easily get lost in too much information and produce results that don't work well (duplicate code or just incoherently solving a problem), and it needs a lot of handholding. Imagine GPT4 (or any other LLM) as a very eager but not very bright junior developer that just started to work with you. It's good, but it'll need a lot of situational management for it to not go wildly off the track. What improved models will bring us in the future is making Pythagora and other such tools work better for large and more complex projects. The tipping point will come when for example you'll be able to load Pythagora in Pythagora and continue development. While we do build some auxiliary/external tools with Pythagora, the core is still handcrafted mostly by a human, and I'm pretty sure that's the case with other code gen tools as well.
nsokolsky 3y ago
I've gotten access to Gemini 1.5 Pro today with a (supposedly) 1M context window and unfortunately in practice it's not good at complicated queries over such a large window, involving multiple recursive lookups back and forth.
hackerlight 3y ago
> Why would would Agents need multiple turns Because it's better. This was the insight behind AlphaGo, AlphaCode and AlphaGeometry. In Go, trying to get the entire solution in one forward pass required a 1000x larger neural net to achieve the same performance according to Noam Brown. Intelligence requires iteration, introspection, planning, sub-task breakdown, and trial and error with feedback from reality (error messages, print statements). These meta reasoning structures (whether hard-coded or, ideally, learned) will move LLMs closer to how humans reason.