Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

StableCode

stability.ai

Post reply on HN
Print view View original

91–100 of 109 posts

Re: StableCode

#91

Post by gsuuon »

thewataccount wrote: post #28
gsuuon wrote: post #19

Earlier quoted context omitted.

I'd really like to see smaller models trained on only one specific language, with it's own language specific tokenizer. I imagine the reduction in vocab size would translate to handling more context easier?

I think simply having the vocab more code friendly (e.g. codex) would make the biggest difference, whitespace is the biggest one (afaik every space is a token), but consider how many languages continue `for(int i=0;`, `) {\n`, `} else {`, 'import ', etc. My understanding is that a model properly trained on multiple languages will beat an expert based system. I feel like programming languages overlap, and interop with…

There's also just far more tokens to train on if you do multi-language. I'd guess only the most popular languages would even have enough training data to get a specialized version - but it would still be an interesting trade off for certain use cases. Being able to run a local code assistant on a typescript-only project for example, with a 32k context window would really come in handy for a lot of people. I don't know enough to understand the impact of vocab size vs context size.

Re: StableCode

#93

Post by pphysch »

maze-le wrote: post #87
pphysch wrote: post #68

Earlier quoted context omitted.

Sure, they can "build" it, but can they maintain it? Can they only add more layers of mud? How do you refactor the statement "Add a button to download the output as a PDF"? That's not a replacement for software engineering.

I thought about this for a while now and I think for the class of problems GP is referring to, no maintenance will actually be needed, the tools will just be discarded re-written again -- at least in one-man projects where no other person than the author is needed to create the tool. Maybe in the future some kind of pseudo-code between real code and natural language will be established. This kind of pseudo-code could…

That makes sense, but never underestimate how easy it is for a throwaway script or tool to become production-ized and a dependency for other production processes.

We've all seen that obscene production workflow built on a Google Sheet or Jupyter Notebook that now needs to support this or that new feature or integration... Add AI-generated tools to the pile.

Re: StableCode

#94

Post by yieldcrv »

Uptrenda wrote: post #52

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

Copium

More people will be able to express themselves, it doesn’t matter that your uncle won’t

Re: StableCode

#95

Post by thewataccount »

gsuuon wrote: post #91
thewataccount wrote: post #28

Earlier quoted context omitted.

I think simply having the vocab more code friendly (e.g. codex) would make the biggest difference, whitespace is the biggest one (afaik every space is a token), but consider how many languages continue `for(int i=0;`, `) {\n`, `} else {`, 'import ', etc. My understanding is that a model properly trained on multiple languages will beat an expert based system. I feel like programming languages overlap, and interop with…

There's also just far more tokens to train on if you do multi-language. I'd guess only the most popular languages would even have enough training data to get a specialized version - but it would still be an interesting trade off for certain use cases. Being able to run a local code assistant on a typescript-only project for example, with a 32k context window would really come in handy for a lot of people. I don't kno…

Its worth noting that from what I can tell - A model well trained in most languages would be able to learn the niche ones much more easily.

The vocab size of llama2 is 32,000. I guess I personally don't think that there's enough difference in programming languages to actually save any meaningful number of tokens considering the magnitude of the current vocab.

Re: StableCode

#96

Post by smcleod »

If I’m reading this correctly this could be an open source model that may compete with the likes of copilot?

That is something I’d be very interested in if they can get the compute requirements down to those of say a standard 13B model. Then I could fine tune (correct term?) it on my offline data and hook it into something like fauxpilot and my IDE.

I had a look at some of the recent code models (wizardcoder,strider etc) but it seemed that you need a really large model to be any good and quite a few of them were trying specifically for python.

Re: StableCode

#97

Post by cyanydeez »

Uptrenda wrote: post #52

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

Shit, even if you give someone all the Lego blocks in the world and a infinity accurate picture of the minimally complex final product, less than 1% would figure it out.

I bootstrapped dev learning by collecting all the necessary pieces of code but at the end of the data I feel like I'm just writing a huge semitechnical novel and the problems I encounter have nothing to do with the basic building blocks, it's entirely about code flow, data flow, entry points, race conditions and things you encounter after you hit 99% of test cases.

This stuff seems like new age "low code" environments.

Re: StableCode

#98

Post by cyanydeez »

Turskarama wrote: post #78
chii wrote: post #59

Earlier quoted context omitted.

> That doesn’t require a precise set of requirements. this exactly. If the AI could make something that semi works, and you check the output, and repeat until you find the output satisfying, then it will be one of the biggest improvements to software development. Sure, you wouldn't use it to write mission critical software such as aviation, etc. But you'd use it to automate the sorting of your email, or write a quick…

Then people will use it in production and hit edge case after edge case. Software engineers have spent their careers learning to spot these in advance and deal with them, while AI will just have to guess what to do, or just let the program crash. Let me tell you, with some of the tickets I've had to deal with I do not think most people could actually describe the problem accurately enough to an AI to actually fix the…

Job postings in 10 years are gonna torture themselves not to name some random model as the only way to churn out bug fixes for some no longer supported model and it's frozen in time language of choice.

Re: StableCode

#99

Post by dragonwriter »

spott wrote: post #54
Uptrenda wrote: post #52

> People of every background will soon be able to create code to solve their everyday problems and improve their lives using AI, and we’d like to help make this happen Yeah, this is not going to happen. Anyone who has ever tried to gather requirements for software knows that users don't know what they want (clients especially lmao.) The language they use won't be detailed enough to create anything meaningful. Do you…

The reason that people need to gather precise requirements that are precise is because the specifications -> product loop is long. Imprecision results in lots of wasted effort. If that loop is shortened drastically, then trying, checking and tweaking is suddenly a much more viable design method. That doesn’t require a precise set of requirements.

> If that loop is shortened drastically, then trying, checking and tweaking is suddenly a much more viable design method.

No, you still need the skill of gathering precise requirements, otherwise you end up in endless churn of implementing the wrong requirements and then implementing the wrong corrections when you get bad corrections.

(Maybe we didn’t know before the general adoption of notionally-Agile development methods, which didn’t have this as there premise but were focused on other benefits of a shortened spec->product loop, we certainly know it after the widespread adoption of those methods.)

Shortened development loop does mean that you are more likely to have the whole market/domain shift under you between the time the requirements are defined and when the system is implemented, though, a frequently-realized risk with big upfront design that renders even precise and accurate (at the time gathered) requirements incorrect when implemented.

Re: StableCode

#100

Post by selfhoster11 »

yohannparis wrote: post #9
runako wrote: post #6

Is this a "product" that one could install and use or a model that one should expect an OEM to integrate into a product before programmers can use it? I'm asking because I don't see any links that would help me figure out how to try it out.

To be honest, you’d better buy GitHub co-pilot and enjoy the productivity boost at a cheap price. Trying to download/install/setup/use StableCode is worth it only if you want to learn all those steps as well. If what you care is the final result, just buy an existing service.

Yeah, why not upload all my employer's proprietary code to Microsoft? What could possibly go wrong?

I get that consuming an API is far easier than setting up your own inference backend, but there are legitimate issues to consider before going in that direction.

Post reply on HN