GPT-4 is quite capable of writing function-length sections of code based only on descriptions. Either in a context where you're not sure what the a good approach is (for myself, when writing Javascript for example), or when you know what needs to be done but it's just somewhat tedious.
Here's a session from me working on a side project yesterday:
The most impressive thing I think starts in the middle:
* I paste in some SQL tables and the golang structrues I wanted stuff to go into, and described in words what I wanted; and it generated a multi-level query with several joins, and then some post-processing in golang to put it into the form I'd asked for.
* I say, "if you do X, you can use slices instead of a map", and it rewrites the post-processing to use slices instead of a map
* I say, "Can you rewrite the query in goqu, using these constants?" and it does.
I didn't take a record of it, but a few months ago I was doing some data analysis, and I pasted in a quite complex SQL query I'd written a year earlier (the last time I was doing this analysis), and said "Can you modify it to group all rows less than 1% of the total into a single row labelled 'Other'?" And the resulting query worked out of the box.
It's basically like having a coding minion.
Once there's a better interface for accessing and modifying your local files / buffers, I'm sure it will become even more useful.
EDIT: Oh, and Monday I asked, "This query is super slow; can you think of a way to make it faster?" And it said, "Query looks fine; do you have indexes on X Y and Z columns of the various tables?" I said, "No; can you write me SQL to add those indexes?" Then ran the SQL to create indexes, and the query went from taking >10 minutes to taking 2 seconds.
(As you can tell, I'm neither a web dev nor a database dev...)
This lines up with my general experience with it. It’s quite proficient at turning a decently detailed description into code if I give it the guard rails. I’ve compared it to having a junior developer at your disposal. They could do a lot of damage if they were given prod access but can come back with some surprisingly good results.
Are you at all worried about what happens if we have a generation of human junior developers who just delegate to this artificial junior developer?
I do. If too many of our apprentices don’t actually learn how to work the forge, how ready will they be to take over as masters someday themselves?
I can see how ChatGPT was useful to the grandparent today, but got very disturbed by what it might portend for tomorrow. Not because of job loss and automation, like many people worry, but because of spoiled training and practice opportunities.
I liked your take, so I’d be curious to hear what you think.
We're eventually going to have to give up on the notion that we must understand the inner workings of the things we build. That's arguably starting to happen now. Not 100% sure it's a bad thing, but it's certainly scary.
We've long since reached the point at which no one can be said to be a true polymath ( https://en.wikipedia.org/wiki/The_Last_Man_Who_Knew_Everythi... ). Having lost the ability as individuals to know something about everything, we're now losing the ability to know everything about anything.
I'm pretty sure that while the most popular programming languages today are Python and Javascript, the most popular ones 10 years from now will be English and Mandarin. Everything we know about software development is about to change. It's about time.
At some point in the past it strikes me people could have made the exact same argument about any higher level language beyond assembly.
The best answer is really if you ask chatGPT "how has the forging of steel progressed since it was invented?".
To me, you are basically worried for no reason about what happens when the apprentices no longer spends their time heating and hammering iron to remove impurities and increase carbon content. There is a trade off involved here. I am sure the apprentices of old understood at a base level what was really going on in the forge better than a modern apprentice but that hardly is an argument against progress.
This is a local SQLite database into which I had slurped a load of information about git commits to do data analysis. If I'd somehow destroyed the database, I would have just created it again.
Biggest one is write overhead: indexes have to be updated every time a record is created or an indexed column is updated. This must be done within the same transaction as the create or update, so you're adding an unnecessary overhead to every single one of those ops. Now, if the data is relatively small or the use-case doesn't warrant it, it doesn't matter.
Lesser issues: additional strain on index rebuilding whenever that happens; messing with execution plans and causing the query planner to be inefficient; primary/secondary memory overhead; or if your DB engine uses locks you can run into a myriad of issues there.
I'm all for SWEs learning about databases, as I'm morally opposed to the proliferation of ORMs and the like, but I don't think ChatGPT is the right way to go about things long-term. It's similar to Googling or using StackOverflow: yes, you will find information that is relevant to what interests you at the moment, but it's soon forgotten and does nothing to help build long-term mental models.
And to be fair, ChatGPT warned me about all of the potential issues with indexes. I did actually evaluate its suggestions and decided they were probably going to be worth the potential cost; and as I've said in a sibling thread, it was just a local SQLite database that consisted of data slurped from another source; so even if I'd somehow screwed the whole thing up, I could just delete it and start over.
Can't wait for the "I don't have a driver license but GPT19 just gives me verbal instructions on how to start the car and drive it. It can't read traffic signs but it's fine I haven't killed anyone yet"
Here's a session from me working on a side project yesterday:
https://chat.openai.com/share/a6928c16-1c18-4c08-ae02-82538d...
The most impressive thing I think starts in the middle:
* I paste in some SQL tables and the golang structrues I wanted stuff to go into, and described in words what I wanted; and it generated a multi-level query with several joins, and then some post-processing in golang to put it into the form I'd asked for.
* I say, "if you do X, you can use slices instead of a map", and it rewrites the post-processing to use slices instead of a map
* I say, "Can you rewrite the query in goqu, using these constants?" and it does.
I didn't take a record of it, but a few months ago I was doing some data analysis, and I pasted in a quite complex SQL query I'd written a year earlier (the last time I was doing this analysis), and said "Can you modify it to group all rows less than 1% of the total into a single row labelled 'Other'?" And the resulting query worked out of the box.
It's basically like having a coding minion.
Once there's a better interface for accessing and modifying your local files / buffers, I'm sure it will become even more useful.
EDIT: Oh, and Monday I asked, "This query is super slow; can you think of a way to make it faster?" And it said, "Query looks fine; do you have indexes on X Y and Z columns of the various tables?" I said, "No; can you write me SQL to add those indexes?" Then ran the SQL to create indexes, and the query went from taking >10 minutes to taking 2 seconds.
(As you can tell, I'm neither a web dev nor a database dev...)