[ramesh31]

>Human writes the easier part -- the test suite, the language model writes the harder part -- the solution. This can be a net gain in productivity.

I've been doing just this with Llama 2 local lately, and I'm convinced that anyone who isn't will be a dinosaur in a couple years.

Fact is, these things are damn good (at JS at least) when dealing with pure unit-testable functions. To the point that I can accept practically any solution it comes up with will be better than mine. Everything is still verified of course, but the days of writing algorithms from scratch are basically over for me.

[hk__2]

How do you avoid overfitting and how do you test performance?

[travisjungroth]

It would be quite hard to overfit with property based tests.

[doctoboggan]

What plugins or other setup is needed to get Llama 2 integrated with your IDE?

[fzzzy]

There's a good one called "Continue" for VS Code. There are also a million copilot chat clones if you search vs code extensions. Probably some of those do it. The vs code extension "Cody" uses anthropic.

[awesomepeter]

Any tips on how to use it locally this way?

[MetaWhirledPeas]

Yeah I'd be interested in watching a demo video, or something like that.

[hughesjj]

How readable is the code? Does it follow SOLID design and the likes?

[ramesh31]

>How readable is the code? Does it follow SOLID design and the likes?

More readable and better commented than my own. The thing is, this isn't generating any kind of "compiler output" type code that you're used to. It writes exactly as a person would. Here's an example I just ran on llama2-7b-chat on my Macbook:

##PROMPT

Llama: My name is Llama. I will write a Javascript function that implements the "emailTest" function, given the following test case that it is expected to pass. I am sure to always fully explain all of my code, and include comments to provide context.

  describe('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => {
    const testVal = emailTest('[e-mail]');
    expect(testVal).toBe('google.com')
  });

##END PROMPT

##RESPONSE

Llama: Here are the test cases:

  test('it takes a string as input, validates that it is an email address, and returns the host name of the email address.', () => {
      const testVal = emailTest('[e-mail]');
      expect(testVal).toBe('google.com')
  })

  test('it should validate email addresses with different domains', () => {
      const testVal1 = emailTest('[e-mail]');
      const testVal2 = emailTest('[e-mail]');
      expect(testVal1).toBe('example.com')
      expect(testVal2).toBe('example.net')
  })

  test('it should validate email addresses with special characters', () => {
      const testVal3 = emailTest('hello@$%^&*()_!');
      expect(testVal3).toBe('example.com')
  })

  test('it should validate email addresses with typos', () => {
      const testVal4 = emailTest('[e-mail]');
      expect(testVal4).toBe('example.com')
  });

Here is the function that I have written to implement the emailTest function:

  function emailTest(input) {
    const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
  
    if (emailRegex.test(input)) {
      // If the input is a valid email address, return the host name of the email address
      const hostName = input.split('@')[1];
      return hostName;
    } else {
      // Otherwise, return an error message indicating that the input is not a valid email address
      return 'Invalid email address';
    }
  }

Can you please provide feedback on my implementation? Specifically, I would like to know if there are any improvements I could make to the function's performance or accuracy.

##END RESPONSE

And from there you can have a conversation with it, and ask it to fix anything that's mistaken. You can also have it extend your test suite with fuzzing and negative cases. This is obviously a trivial example, but you get the idea. I haven't been able to stump it yet.

[johnnyworker]

    const testVal3 = emailTest('hello@$%^&*()_!');
    expect(testVal3).toBe('example.com')

At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case?

[ramesh31]

> At the risk of terribly embarrassing myself, shouldn't the expected result be "invalid email address" in this case?

Indeed. This particular test case got jumbled up, but you should always be verifying the output anyways. You can ask it to correct itself when this happens, i.e.:

  User: That's wrong. The test would return 'Invalid email address' here, not 'example.com'

  Llama: Ah, I see! Thank you for correcting me! In that case, here's the modified test case:

  test('it should validate email addresses with special characters', () => {
    const testVal3 = emailTest('hello@$%^&*()_!');
    expect(testVal3).toBe('Invalid email address');
  })

  Llama: Now, when the `emailTest` function is called with the input 'hello@$%^&\*()_!', it will return 'Invalid email address' instead of 'example.com', because the
  input does not match the regular expression pattern defined in the function.

[jprete]

There are other problems in there in addition to that one, but it isn’t clear to me that the GP is intended to be an example of completed good output.

[fzzzy]

Is writing System prompts in first person better than writing them in third person?

[ramesh31]

> Is writing System prompts in first person better than writing them in third person?

That's what I've found. Llama doesn't really seem to have a concept of "you" or "they". But if you make it assume that it is something specific, and that it is doing something, it will continue doing that thing.

[jprete]

What is the most difficult thing you’ve gotten it to do?

[ramesh31]

>What is the most difficult thing you’ve gotten it to do?

It's particularly good at recursive tasks I don't want to expend the mental effort on. I.e:

  Llama: I am Llama, a programming assistant. Please provide me with a task.

  User: Thanks. Here is a data structure. Write a Javascript algorithm which will recursively parse the structure to collect all 'id' properties into a single array.
  Be sure to check the input and not cause any errors which could result in an infinite loop.

  ```
  const data = {
      'id': 'test1',
      'nodes': [{
          'data': {},
          'list': [{
              'id': 'test2',
              'values': [{
                  'id': 'test3',
                  'name': 'val'
              }]
          }]
      }]
  }
  ```

  Llama: Sure thing! Here is the algorithm in Javascript:

  ```
  function parseId(data) {
    const idArray = [];

    // Recursively traverse the data structure
    function traverse(data) {
      Object.keys(data).forEach((key) => {
        if (key === 'id') {
          idArray.push(data[key]);
        } else if (typeof data[key] === 'object') {
          traverse(data[key]);
        }
      });
    }

    // Start the recursion
    traverse(data);

    return idArray;
  }

  parseId(data) // Output: ["test1","test2","test3"]
  ```