That’s kind of a point for it? If the code isn’t the product, then it doesn’t matter who made it if the product is built properly. And sota models certainly know where to put the nails.
A better analogy would be a 3d printer. Much quicker than carving stuff out of wood. Might fail a print but it’s still faster. It’s not exactly food safe so avoid using it for something important. Obviously, it works well for small things but trying to build a house out of 3d printed bricks is going to yield failure.
Not the best analogy though but nails and hammers and monkeys is just missing the point completely imo.
Not sure what you mean by this tbh. The client list in relation to the product? Do you mean the source code leak? That’s a bit what I mean by it not being safe for everything and trying to build a house out of 3d printed bricks. I’m not even certain the code leak was caused by AI generated code anyways.
I personally only build small internal apps for the rest of the team. We don’t ship software.
Granted, every tool has its use and most can be used for the wrong thing if you try hard enough. It’s also easier to use it for the wrong thing with AI, has to be said.
think of it like this. you build small tools for internal use, so code quality, maintainability and documentation are not your highest priorities, right? most important is to ship the features needed by your colleagues right now. i’ve been in that same boat, building internal testing tools for a big multinational.
say your tool contains shortcuts for interacting with some internal database. you don’t need auth because it’s all on the internal net, so it’s just a collection of shortcuts. you don’t really care about maintainability, because it’s all just temporary, so you throw every new request together in the fastest way you can, probably trying out new techniques to keep yourself entertained. you don’t really care about testability, because you’re the only one testing so you can check that everything works before doing a release and if something slips through one of your colleagues will walk down the hall and tell you.
now imagine it gets enough attention that your boss says “we want our customers to use this”. suddenly your priorities are upended: you absolutely need auth, you definitely need testability and you absolutely definitely need the tool to not mess things up. best possible world, you can reimplement the tool in a more manageable way, making sure every interface is consistent, documentation is up to snuff for users, and error handling is centralised.
the claude cli leak is the opposite of that. it’s the worst code quality i’ve ever seen. it’s full of errors, repeated code, and overzealous exception handling. it is absolutely unmaintainable. the functionality for figuring out what type a file is and reading it into a proper object is 38 000 lines of typescript, excluding the class definitions. the entire thing is half a million lines. the code for uploading a pdf calls the code to upload jpegs, because if a file isn’t identified it’s automatically a jpeg. and jpegs can go through the same compression routine up to 22 times before it tries to upload them because the handler just calls itself repeatedly.
and this is the code they thought was robust enough to withstand the internet. imagine what their internal tooling looks like.
code is not the product. code is the tool we use to build the product. it’s not about swinging your hammer, it’s about knowing where to put the nails.
That’s kind of a point for it? If the code isn’t the product, then it doesn’t matter who made it if the product is built properly. And sota models certainly know where to put the nails.
A better analogy would be a 3d printer. Much quicker than carving stuff out of wood. Might fail a print but it’s still faster. It’s not exactly food safe so avoid using it for something important. Obviously, it works well for small things but trying to build a house out of 3d printed bricks is going to yield failure.
Not the best analogy though but nails and hammers and monkeys is just missing the point completely imo.
after the client leak i should think it was even more poignant. a bit like tearing down a wall and finding it full of mouldy razor blades
Not sure what you mean by this tbh. The client list in relation to the product? Do you mean the source code leak? That’s a bit what I mean by it not being safe for everything and trying to build a house out of 3d printed bricks. I’m not even certain the code leak was caused by AI generated code anyways.
I personally only build small internal apps for the rest of the team. We don’t ship software.
Granted, every tool has its use and most can be used for the wrong thing if you try hard enough. It’s also easier to use it for the wrong thing with AI, has to be said.
think of it like this. you build small tools for internal use, so code quality, maintainability and documentation are not your highest priorities, right? most important is to ship the features needed by your colleagues right now. i’ve been in that same boat, building internal testing tools for a big multinational.
say your tool contains shortcuts for interacting with some internal database. you don’t need auth because it’s all on the internal net, so it’s just a collection of shortcuts. you don’t really care about maintainability, because it’s all just temporary, so you throw every new request together in the fastest way you can, probably trying out new techniques to keep yourself entertained. you don’t really care about testability, because you’re the only one testing so you can check that everything works before doing a release and if something slips through one of your colleagues will walk down the hall and tell you.
now imagine it gets enough attention that your boss says “we want our customers to use this”. suddenly your priorities are upended: you absolutely need auth, you definitely need testability and you absolutely definitely need the tool to not mess things up. best possible world, you can reimplement the tool in a more manageable way, making sure every interface is consistent, documentation is up to snuff for users, and error handling is centralised.
the claude cli leak is the opposite of that. it’s the worst code quality i’ve ever seen. it’s full of errors, repeated code, and overzealous exception handling. it is absolutely unmaintainable. the functionality for figuring out what type a file is and reading it into a proper object is 38 000 lines of typescript, excluding the class definitions. the entire thing is half a million lines. the code for uploading a pdf calls the code to upload jpegs, because if a file isn’t identified it’s automatically a jpeg. and jpegs can go through the same compression routine up to 22 times before it tries to upload them because the handler just calls itself repeatedly.
and this is the code they thought was robust enough to withstand the internet. imagine what their internal tooling looks like.
Not just where to put the nails but also how hard to swing the hammer, when to stop swinging it, etc.