I treat its output like I would treat a PR from a brand new apprentice engineer on my team: review it carefully, provide some feedback and iterate a few times, accept with tests.
E.g. some tasks I've used it for recently:
* Giving me an outline of a JMAP client so I can pull down stuff from my e-mail to feed to GPT.
* Giving me an outline of an OpenAPI client.
* Giving me an index page and a layout for a website, including a simple starting point for the CSS that did a reset and added basic styling for the nav bar, forms and "hero "sections.
* Giving me an outline of a Stripe API integration.
* Writing a simple DNS server.
* Writing a simple web server capable of running Sinatra apps via Rack.
None of these were complex code that'd hide obscure bugs. None were big chunks of code. All of them were simple code that was always going to have big, gaping holes and sub-optimal choices that'd need to be addressed, but that was fine because they were scaffolding that saved me starting from scratch (and the last two were not intended to turn into anything, but just exploring what it could do)
That's where the biggest savings are for me, because if I asked it to generate particularly complex stuff, I'd end up spending ages getting comfortable it'd done it right and verifying it. But the simple but tedious stuff is something it's great for.
> I'm at the point where I'm preparing to integrate models all over the place
Nobody understands these models right now. We don’t even have the weights.
You may draw some artificial distinction between literally checking in the source code of a model into your git repo and making a call to some black box API that hosts it. And you may claim that doing so is no different than making a call to Twilio or whatever, but I think there is a major difference: nobody can make a claim about what an LLM will return or how it will return it, cannot make guarantees about how it will fail, etc.
I agree with zer00eyz.
You're jumping to conclusions not supported by the comment at all.
Also, the comment has two parts: One about writing code, and one about integrating models in workflows.
To the latter, the point is that for a whole lot of uses you can trivially ensure the failure modes are safe.
E.g. I am integrating gpt with my email. "Mostly ok most of the time" applies to things like e.g. summaries and prioritisation, because worst case I just get to an email a bit later. "Sufficient checks" applies to things like writing proposed replies: There's no way I'd send one without reading it, and it's sufficient for me to read through it before pressing send (and making adjustments as needed). Failures here would matter if I intended to make a product of it, but as a productivity tool for myself it just needs to be close enough.
There are a whole lot of possibilities like that.
But even for coding related tasks there are a whole lot of low risk tasks,such as e.g. generating HTML or CSS, or provide usage examples, or providing a scaffold for something you know well how to do but which are time consuming.
If you're trying to make it do things that'd be time consuming to verify sufficiently well, then that's a bad use. The good uses are those where errors are low impact and easy to catch.
> You’re jumping to conclusions not supported by the comment at all.
That might be true, but you’re making assumptions that your first comment is clear and being interpreted the way you intended. I think it’s fair to point out that your words may imply things you weren’t considering, that asking people to re-read the same words again might not solve the problem you had.
The bigger picture here is that you’re talking about using AI to write code that for whatever reason you couldn’t write yourself in the same amount of time. The very topic here also implicitly suggests you’re starting with code you might not fully understand, which is fine, there’s no reason to get upset because someone else disagreed or read your comment that way.
I work in code security, and after helping any number of customers, I can tell you this isn't how far too many programmers work.
A client recently had a problem with a project that had over 1200 node_modules.
1200...
Let that sink in. There is absolutely no way in hell they even had any idea about a small portion of the code they were including.
# of Node modules is such a useless metric.
In any given project, a large # of node modules are part of the test, build, and linting frameworks.
If I go to C++ land and count the number of #import statements, it wouldn't tell me anything.
How many classes do large Java projects use? Typically some absurd number.
I had a conversation with ChatGPT where I asked it to write me a piece of code. After it wrote the code, I reviewed it, and I told ChatGPT that it had a subtle bug. ChatGPT then fixed the bug itself, and wrote an English description about how the fix it added would prevent the bug.
Im an old engineer.
Simply put NO.
If you don't understand it don't check it in. You are just getting code to cut and paste at a higher frequency and volume. At some point in time the fire will be burning around you and you won't have the tools to deal with it.
Nothing about mostly, much and sufficient ever ends well when it has been done in the name of saving time.