>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.
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.
>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('[email protected]');
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('[email protected]');
expect(testVal).toBe('google.com')
})
test('it should validate email addresses with different domains', () => {
const testVal1 = emailTest('[email protected]');
const testVal2 = emailTest('[email protected]');
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('[email protected]');
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.
> 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.
> 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.
>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"]
```
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.