Think about it, one well paid profession in the grips of capital siphoning off valuable, highly intellectual work (by using "open source" already), repackaging it and the selling it back to the people it aims to replace.

Imagine a million lawyers' days being recorded in 60s intervals - including what they type, the files they have opened, etc. - how long would it take to encode the average lawyer into a hdf5 file? How many lawyers would be fine with that kind of assistance?

If that's not ingenious, then I do not know what is.

Call to action: Programmer, wake up.

Edit: Just to address some typical rebuttals - I'm all for progress and cool toys, but I'm all against monopolies and mega-corps that control and monitor every aspect of your life.

Look at stackoverflow for example. Thousands of programmers giving away their professional advice, spending their valuable time…for what exactly? Imaginary internet points?

Open source is another one: here’s my code that I’ve worked so hard on, spent countless hours on - please have it for free, my labor is worthless.

It’s like they’re actively seeking to bring their own value down.

Before Stackoverflow, people were answering questions on USENET newsgroups without any award of points.

And before USENET and the internet, hobbyists would gather to trade advice on building home computers. E.g.: https://en.wikipedia.org/wiki/Homebrew_Computer_Club

The common theme isn't the points... it's that people like to be helpful and share knowledge.

>Open source is another one: here’s my code that I’ve worked so hard on, spent countless hours on - please have it for free, my labor is worthless.

There are multiple motivations for open source. In my case, I did it because I could get more value from the community's enhancements than the "free code" the community got from me.

>It’s like they’re actively seeking to bring their own value down.

Neither of your 2 examples look like erosion of labor value. On the contrary, it shows that not every activity associated with programming has to be driven by the exchange of money.

Or, at least, it's only "labor" in the same sense that literature or painting is labor.

Does it seem strange to you that writers or painters would want the world to see their work, even for free? It doesn't seem strange to me.

Programming is the same.

What about this discussion we are having right now on here about this topic?

Why bother just for useless upvotes? No one is even paying me to think about this.

I can't agree with this. Programming can be like literature. It can also be like writing copy for a bad travel brochure.

It's true that software developers need to eat too but we need to figure out a way to do so without making the world more cumbersome, transactional, and shitty.

I’d estimate something like 99% of all software development (especially, perhaps, open source) is either for toys or else actively harmful. “Betterment of the species” indeed.

How do you reason? Are Linux, sqlite, LLVM, or OpenSSL actively harmful? KDE? Blender? Those are obviously not "toys" and each seems genuinely helpful and useful to me.

If software engineers want to contribute in that way, they should support the research efforts of individuals in the areas I mentioned. Those projects are meaningful and impactful. But they're a tiny fraction of software developed.

It's simply an incredibly ignorant conceit to fancy oneself as providing even small impact simply because one writes some software.

[0] https://www.swyx.io/learn-in-public/

If you can't understand why someone would decide to offer their help for free then at least try to be thankful.

Basically what motivates good engineers is a good problem. If we can meet our basic needs we give the rest away for free. Companies/entities have been using/exploiting this for years. The gamification points are lame (I agree) but I believe there is a general desire to contribute to the common good and give back to the community.

https://thecreativeindependent.com/people/philip-glass-on-co...

That's weird logic. Presumably you wouldn't create something you consider worthless - you'd create it because you needed it.

When I participated on Stack Overflow, for me it was a combination of learning a lot by answering other people's questions and getting a kick out of demonstrating my expertise.

Just take my day today: interpreting the client's specs and internally communicating and planning a minor change in the context of a few parallel release paths, discussing a few tweaks to a piece of code with a colleague carefully weighing effort, impact on partially rolled out tests, and future flexibility (making best guesses as to where things are going), and analysing / fixing an issue in a piece of code which design delicately balances simplicity, robustness and performance.

Call me naive but I don't see an AI taking over before reaching (or nearing) general AI. Nor do I see how someone that's not a competitor already become one just by having access to Stack Overflow, or even a tenfold of it.

Open source is a great way to market yourself. If I have some really valuable code, then I'll keep it for myself. If I think it would be more useful and gain traction as an open source project then I might publish it and in that way position myself as the top expert on that software.

A lof of businesses are actively using, publishing and contributing to open source. Not because they don't want to make money, but because it's the way to make money.

The opposite is true. Analogy: Volvo invented the three point seatbelt. To maximize the value of the invention, they gave it away free to use.

I'd say, minimally, a good 50 years, except perhaps for the busywork. At that point you could maybe have a tool that could handle a lawyer's job. Law's often an extremely creative, verbal, expressive job, so I think machines are particularly unlikely to do well there.

I'm not worried about being automated away. If someone wants to make coding easier, neat, I'm not a programmer, that's just how I get shit done. I solve complex problems, and I don't see machines taking that job for a long, long time.

Frankly, if machines can take away the mechanical bullshit part of a job and let us humans do the interesting, creative work, that works for me.

How much "interesting, creative work" is there? Surely most of the work that most of us do, and that most of us are capable of and interested in, is not simultaneously interesting and creative.

I count myself as lucky and I have certainly had a more interesting working life than average but the proportion of that forty years of work that counted as both interesting and creative is probably, looking back on it, measured in single digit percentage points.

If a machine does all the easy stuff how would I ever get enough practice to stretch myself to the difficult creative parts?

I would imagine that the answer is roughly "infinite". It's like asking "how much art is there?" - infinite.

> If a machine does all the easy stuff how would I ever get enough practice to stretch myself to the difficult creative parts?

By doing the easy stuff? I don't know, you can do whatever you want.

The machine is doing the easy stuff. Why would anyone pay a human to do it? If I am not being paid how will I get the resources needed to be able to spend time working on the easy stuff?

(stuff being done for me: CPU design and work with the OS on top of it including multithreading and IO, executing database operations, turning higher level commands into tons and tons of machine language instructions, libraries that allow me to go higher and higher in abstraction level, think synchronising, multi threading, basic data structures like dictionaries, map/filter/reduce operations, etc - where I need to I learn about them, but mostly I just use them and let them do the heavy, boring, lifting)

(working with a low code solution like Mendix is comparable, you can become creative without the boring work, of course it has a learning curve, which learns you how to use the higher abstraction layers without the need to really practice or fully understand what it takes out of your hands)

Law can be pretty verbose. Given half a paragraph, how often can an intelligence (artificial or natural) deduce what's next?

Of course the coding AI has the advantage that coders write (and publish) comments.

And writers in law write commentaries, some of them having great authority.

The article also mentions - "head of AI products at the St Petersburg office of JetBrains, a Czech developer of programming software, sees time savings of 10% to 20%. "

and the subheading says - "The software engineers of the future will, themselves, be software"

um, how seriously should we consider the fact that "skilled" software engineer/programmer solving really complex problems are at risk?

Can't say if making just another simple CRUD app is not at risk but the statements and their propositions made in the article are too generalize too plant a seed of insecurity in oneself.

I dare posing that by the time AI takes over my job, it's gotten so advanced that I've got much more to worry about than just my job.

Once I've solved a problem, I document it in code. Only seeing the code at the end misses the problem solving parts

As a programmer though, I’m not worried. Every line of code is generating more code. Every recursive function, every loop, every piece of meta programming. Every script file that calls a Python program that calls c routines that microcode that call actual ops. It’s already all generated code generating more generated code.

When (if) we have full AGI that is capable of truly understanding a real world problem and kicking off a chain of code generation and is affordable, then I’ll be worried.

Pretty sure that large law firms already automate a lot of the work they do. Standard contracts they customize for instance.

But really, aren't a lot of (billables) hours spent explaining legal concepts to customers?

* I should elaborate. We tend to easily accept the "this work is meaningful" line, we volunteer our time because "programming is a craft," and we will hop on tooling bandwagons like this because it's shiny and new without considering the ramifications.

The term comes from this, and uncovers a bit of the futility about the so-called benefits of playing the imitation game:

https://www.steveglaveski.com/blog/the-curious-case-of-cargo...

The problem is that in the fast-paced corporate world, you either make your own startup (and usually fail at that), or you have to play the same game everyone else does. There's simply not enough time and resources to get ahead at everything. Unless you go for the smaller niche, ie. embracing agility. Of course, everyone and their mother is Agile (tm) these days too!

The key feature of cargo-culting is immitating another without understanding the why behind what they're doing.

Imitating is simply imitating. Many companies have gotten rich doing this.

https://en.wikipedia.org/wiki/Hydrox

Developers have a massive proclivity to follow something simply because others have. We're talking everything from best practices to design methodologies to whether or not to include a semicolon at the end of a line. There's a reason for this: writing software is very hard to measure and quantify. It's not a physical thing like a bridge or an automobile. When we hear about some new paradigm/framework/language/etc. espoused by some blue-checkmark-wielding developer who works at Google, we pay attention because...he works at Google, and seems like a trusted figure.

Not saying this is good or bad, it's just how it is.

First it was accessible programming languages (BASIC, Pascal, etc. ~1970s/80s), then it was standard software (spreadsheet software, ERM packages, etc. 1990s), then low code/no code (early 2000s), then model-/requirement driven (Rational Rose etc., late 90s, early 2000s), in between it was visual "programming" every now and again, now it's back to low code/no code again.

As long as the mechanical systems cannot test requirements for contradictions, don't accept non-functional requirements such as performance or security and produce non-correctness proven results that even fail to compile or are syntactically incorrect from time to time, I have no fears.

The current situation might as well be a local optimum in which NLP/ML will be stuck for quite a while. It's really hard to tell, but I don't see any reason for starting to panic just yet.

From my point of view (my field of study is basically program synthesis for logic programs) code generation with large language models is not really comparable to what can be achieved with traditional program synthesis approaches.

The main advance seems to be in the extent to which a natural language (i.e. English) specification can be used, but natural language specifications are inherently limited because of the ambiguity of natural language. Additionally, trying to generate new code by modelling old code has the obvious limitation that no genuinely new code can be generated. If you ask a language model to generate code it doesn't know how to generate - you'll only get back garbage. Because it has no way to discover code it doesn't already know how to write.

So Copilot, for example, looks like it will make a fine boilerplate generator - and I'm less skeptical about its utility than most posters here (maybe partly because I'm not worried my work will be automated) but that's all that should be expected of it.

Reminds me of this essay that pg wrote in 2005, titled The Submarine. Someone linked it in another thread here on HN recently.

> One of the most surprising things I discovered during my brief business career was the existence of the PR industry, lurking like a huge, quiet submarine beneath the news. Of the stories you read in traditional media that aren't about politics, crimes, or disasters, more than half probably come from PR firms.

http://www.paulgraham.com/submarine.html

First, I've never heard of program synthesis, and it seems like an interesting topic. Could you point me to some resources so I can learn more about it?

Second. I take issue with this statement:

> "trying to generate new code by modelling old code has the obvious limitation that no genuinely new code can be generated"

I disagree. We've seen GAN's generate genuinely new artwork, we've seen music synthesizers do the same. We've also seen GPT-3 and other generative text engines create genuinely interesting and innovative content. AI dungeon comes to mind. Sure, it's in one way or another based on it's training data. But that's what humans do too.

Our level of abstraction is just higher, and we're able to generate more "distinct" music/code/songs based on our own training data. But that may not hold in the long term, and it also doesn't mean that current AI models can do nothing but regurgitate. They can generate new, genuinely interesting content and connections.

I'll leave it to the GP to give a lit review, but will say that CS has (always had) a hype-and-bullshit problem, and that knowing your history is good way to stay sober in this field.

> We've also seen GPT-3 and other generative text engines create genuinely interesting and innovative content.

Making things humans find entertaining is easy. Markov chains could generate genuinely interesting and innovative poetry in the 90s. There's a Reply All episode on generating captions for memes or something where the two hosts gawk in amazement at what's basically early 90s tech.

> They can generate new, genuinely interesting content and connections.

Have you ever dropped acid? You can make all sorts of fascinating content and connections while hallucinating. Seriously -- much more than when you're sober. Probably shouldn't push to prod while stoned, though.

Art and rhetoric are easy because there's really no such thing as "Wrong". That's why we've been able to "fake creative intelligence" since the 80s or 90s.

Almost all software that people are paid to write today is either 1) incredibly complicated and domain-specific (think scientists/mathematicians/R&D engineers), or else 2) interfaces with the real world via either physical machines or, more commonly, integration into some sort of social processes.

For Type 1, "automatic programming" has a loooong way to go, but you could imagine it working out eventually. Previous iterations on "automatic programming" have had huge impacts. E.g., back in the day, the FORTRAN compiler was called an "automatic programmer". Really.

For Type 2, well, wake me up there's a massive transformer-based model that only generates text like "A tech will be at your house in 3 hours" when a tech is actually on the way. And that's a pretty darn trivial example.

There is a third type of software: boilerplate and repetitive crap. Frankly, for that third type, I think the wix.com model will always beat out the CoPilot model. And it's frankly the very low end of the market anyways.

The following is a comprehensive introduction and survey of recent work in the field:

https://www.microsoft.com/en-us/research/wp-content/uploads/...

Regarding novelty, neural networks are excellent at interpolation but awful at extrapolation. What I mean by interploation is that the models learned by a neural network represent a dense region of cartesian space circumscribed by the neural net's training instances. The trained model can recognise and generate instances included in this dense region, including instances not included in its training set, by interpolation, but it is almost completely incapable of representing instances outside this dense region by extrapolation [1].

So basically what I'm saying above is that deep learning language model code generators can't extrapolate to programs that are not similar to the programs they've been trained on. Hence, no real novelty. But you can go a long way without such novelty hence my expectation that e.g. Copilot can be a nice boilerplate generator.

______________

[1] My standard reference for this is the following article by François Chollet, maintainer of Keras:

https://blog.keras.io/the-limitations-of-deep-learning.html

See also the second part of the series of articles where possible ways are proposed to address this limitation:

https://blog.keras.io/the-future-of-deep-learning.html

The latter is relevant to the conversation because the author basically proposes augmanting current deep learning approaches with a form of program synthesis.

Look up the work of Cordell Green. He invented the idea and built a company around it.

https://www.kestrel.edu/people/green/

Since my first programming job, I've generated code in whatever language I'm using with that language. SQL from SQL, Perl from Perl, etc. And/or regular expressions.

This page:

https://en.wikipedia.org/wiki/Metaprogramming

leaves the impression that using programs to make programs requires a special language or special features, and it was rather a dead end in AI.

I think what you describe is the task of putting together parts of a program according to a configuration. That's a related task and you could certainly see it as a kind of program synthesis, but because it's a common task that we know how to do well, it's not really what program synthesis research is focused on.

Some programming languages are definitely better suited to program synthesis than others. That's particularly the case with languages that have little of what I'd call "ceremony", syntax that's not really necessary to express the behaviour of a program, but are there to help the programmer organise the code, such as classes, maybe, or interfaces, say.

I don't know that metaprogramming was a dead end in AI. I hear that a lot for many subjects of AI research that are still active. I mean, if you asked machine learning researchers ten years ago about neural networks they'd tell you "it's a dead end", or "we tried that and it didn't work" etc. So, unless you're very knowledgeable about a subject of AI research my suggestion is to be cautious when extracting conclusions from a perfunctory perusal of wikipedia or blog posts etc. That's not where most of the knowledge is stored for such deep subjects as AI research.

This sounds like a description of a parser generator.

When I post in conversations like this I do it in the hope that my comments will invite robust debate from knowledgeable contributors, that will challenge my assumptions and my knowledge and help me refine my understanding of the subjects I am interested in. This comment is really so much not that, that it hurts.

https://sunblaze-ucb.github.io/program-synthesis/index.html

I think of large LMs trained on code as something that will sample strings from the space of "code humans might write". This isn't nothing, but as you say it's unlikely to produce programs that solve problems no human has solved before. However, assuming you have a rigorous enough spec, I don't see why you couldn't use something like reinforcement learning on such a model in conjunction with traditional verification tools...

Anyway, I agree it's unfortunate that program synthesis has been overlooked in the latest AI code generation craze -- I've mentioned it to a few journalists when talking about things like Copilot but it doesn't tend to end up in the final article.

I'm pretty sure that as you say deep learning will be used for program synthesis, in fact it already has - the article above mentions a few applications and startups etc. I'm really curious to see how all this will pan out a few years from now. But the applications that are developed commercially are really trying to implement programming aids, rather than solutions to the full program synthesis problem, which, in a nutshell, is to be able to generate arbitrary programs from a specification of some sort.

I'm skeptical that deep learning can really solve this more general (and much harder) problem. The reason I'm skeptical is that neural networks are great approximators but they're not known for their great precision, I guess. With program synthesis the point is usually to really get a program that does what the specification says, no ifs and buts and no 80%-there's. I don't know how neural netwokrs can do in this, but I don't think the answer is "very well".

>> Anyway, I agree it's unfortunate that program synthesis has been overlooked in the latest AI code generation craze -- I've mentioned it to a few journalists when talking about things like Copilot but it doesn't tend to end up in the final article.

Well, thanks for fighting the good fight :)

You've piqued my curiosity, of course. Can you share one of the articles you mention?

https://www.wired.com/story/ai-latest-trick-writing-computer...

https://cacm.acm.org/news/253785-will-ai-rewrite-coding/full...

I think my optimism for deep learning methods here comes not from their ability to generate code from scratch but as a way to guide a search process in the space of programs. By analogy, Go and chess are also domains where approximations won't do, but DNNs have had excellent success in finding better search strategies for the game tree. That's the kind of thing that I think might be successful here.

Yes, there seems to be a trend of using deep learning to guide classical search. The first time I noticed it was in AlphaGo. I was initially skeptical but it seems to have picked up and be producing results.

Personally I'm not interested in that approach very much because my work is on constructive approaches, that completely avoid a search. Don't let me bore you with it (it's my doctoral research... you know how students get with their theses :) but there's links in my sig if you're curious.

And thus the ball is moved back to the human programmers court, as it has since Cobols sentences and paragraphs were supposed to allow managers and business analyst to write code.

I'm actually surprised about the Maruary, Apruary etc error. That is something that FlashFill should be able to handle very well. Strange.

Do you have a link to some post or comment etc with more context about that gif? Maybe it was an older version of the tool? It works correctly (generates month names) in my version of Excel (360 I think?).

Although I do see the Maruary etc error while I fill-in "February" (but not after I drag the cross-handle thingy down).

I’m optimistic about the prospects of some combination of logic solvers and deep learning. As you mention, natural language specs are only approachable with a language model. I think logical constraints could function as really powerful regularization on the output of neural network code gen. Like, constraining output to only programs that satisfy logical constraints inferred from the language.

Also, some forms of programming are super non-trivial to describe and are much more easily specified with input output pairs. This is where the more traditional synthesis approaches really shine. Excel flashfill works astoundingly well for this.

>> Also, some forms of programming are super non-trivial to describe and are much more easily specified with input output pairs.

I agree of course, but then I would, wouldn't I? That's the kind of thing I'm studying...

The Gulwani et al. work behind FlashFill made a huge impression in program synthesis circles when it first came out.

In the mid-term this is great for sub-mediocre AI users who seemingly get a boost in performance/quality, etc, but people tend to not recognize that in the long term there is a dangerous feedback loop. AI models just regurgitate their training, pretending it's state of the art.

Every now and then people bring up the fact that relevant long tail Google results are no more. Every time we click through on the first page, we are collectively training google to be mediocre and in exchange it's training us to be the same.

We had the same debate around criminal profiling, insurance, credit ratings, automated censorship, even 'art'.

Programming won't be that different. It will be even useful in a limited sense. AI will give a lot of mediocre results for mediocre questions and the wrong answer for 'new' questions, but we won't know which one is which. But remember that in the long term we are feeding the outcome back to the models, so it's not real progress, it's just a proliferation of "meh".

Actually humans have an issue here, since the majority of humans are mediocre at what they do (Bell curve and all that). Thus AI assistants threaten to replace the majority of humans.

Is it me or is the Economist much more unabashed these days about representing the fevered dreams of business elites? (as opposed to engineers who know wtf theyre talking about)

This copilot circus reminds me of a restaurant I used to go to went to shit in ~2015 because the owner thought giving iPads to customers meant they could cut payroll by 20%.

Which was very much in vogue at the time:

http://images.gawker.com/itqtvwbe3c0skb99wirm/c_scale,fl_pro...

What went wrong? At some fast food places the ordering machines definitely displaced some of the cashiers. I'm surprised customers wouldn't go for tablets if it meant they didn't have to pay the 15% tip.

To use a fast food example, I somewhat regularly go to a McDonalds when we road trip (I have kids, don't shame me) and they have ordering screens. It takes easily 5x as long to answer all of it's questions about permutations on the meal I want than to just say "gimme a #2 with Dr Pepper, no pickles" to a cashier.

Maybe if they put in a proper voice assistant it would be better. But the touchscreen is not in any way a superior experience.

It's not even clear that it would be efficient for the customer to learn it, even if they were willing, given how rarely most people eat out and how quickly memory degrades with disuse.

I saw this issue with NJTransit ticket machines as well. They suck compared to NY subway.

NJTRansit: https://www.youtube.com/watch?v=avNAwTJStwU

There are so many tiny improvements to speed they could do to make it a better experience, the tiny delays between menus add up, the printer is slow and has multiple delays. This all adds up and I have experienced the brunt end of then whenever I am rushing to catch a train.

NY Subway: https://youtu.be/jcrrb48vzfY?t=87

Notice how each screen transition is instantaneous. The money scanning is super fast and the ticket(card) dispensing is quite fast as well. If you are a frequent user, you can fly through this screen and this represents a real marked improvement over human interaction, there is no way you could replicate that speed with a human teller.

Try the app on your phone: you can just go into your previous order and order it again. Really, I like the kiosks, but they can't get compare to an app ordering experience because the latter benefits from history.

The UI for a POS is designed for efficiency (because the worker will get lots of practice using it) rather than accessibility (a customer won't use the UI so much, so it has to be easy to use).

The prices werent any lower they just had fewer staff. Presumably the owner thought they could collect higher profits.

It seems to have become quite normalized to put tip jars out for all sorts of businesses that aren't really service-based. Setting the expectation. Or putting on a tip line on the credit card receipt -- sure, you don't have to tip, but we want you to think you're abnormal if you don't.

I don't think switching to tablets would do anything to reduce the expectation of tips.

And it hasn't been 15% for years.

They don’t have to tip to start with. And the ones with the most problem with it won't, or will tip less.

And people go to places that aren't fast food because, at least in part, of service, which iPad’s don't provide the way servers do.

I'm not even convinced that the effect will be positive. A habit of blindly accepting copilot suggestions could lead to more bugs.

I don't think it really understands code, only very superficially (unlike GPT-3 which might actually genuinely understand parts of language, computer code requires more abstracted mental model). ELIZA was similar, some people also believed that it can understand what they are thinking. Turns out it was all just in our heads.

Shouldn't computer code be simpler to understand and express than natural language? The amount of knowledge about the world is much smaller and mostly concerns artificial systems. And of course programming languages are laughably simple and well defined compared to the constantly evolving mess that is the English language.

And that's what I am alluding to with my entropy comment. Factor's syntax has extremely high entropy (if we look at words as tokens), or rather, it is designed to allow extremely high entropy of code.

Ultimately, I think it comes down to preference, what the tools should be doing for us programmers? Should the program source code (language syntax) have low entropy, and the tools should exploit that when we write the code (as Copilot does), or should we strive for as high entropy of the source code as possible, and have the tools explain the context for us (for example, in Factor, it would be what the expected types on the stack are in the certain place in the code, etc.)? I am in favor of the 2nd approach, I think that is going to be more productive.

Yes, but the ideas that are being expressed in formal languages are much more complex and detailed than the ideas that are being expressed in natural language.

Writing some plausibly on-topic blog posts is way easier than writing even a very simple program, especially if you don't really know what you're talking about.

ELIZA is clearly a toy, Copilot is something that could become integrated with the workflow of a professional developer. Maybe not copilot specifically, but if Intellisense is in our IDEs already, something like it is not a stretch.

> I don't think it really understands code

It clearly doesn't, but (a) nobody actually claimed that outside of the usual media circus, and (b) that's a very high bar. It doesn't need to understand your code in order to be useful.

I don't deny that good suggestions are useful in coding. I am just not sure you can get these by mimicking other people's code without really understanding it.

I think the reason why code is different than natural language is that in code, the meaning of identifiers (words) is very dependent on the context of the specific codebase, and not nearly as universal as in natural language. Sure, there are words like personal names in natural language that change meaning depending on wider context, but they are not as common in the natural text.

So focusing on the names only, rather than for example understanding types of runtime objects/values, and how they change, can be actually actively harmful in trying to understand the code and making good suggestions. So I would believe that suggestions based on e.g. type inference would be more useful.

There is another aspect to this, text has inherently low entropy, it's somewhat easy to predict the next symbol. But if code has low entropy (i.e. there are universal patterns that can be applied to any codebase in a particular programming language), I would argue that this is inefficient from the programmer's point of view, because this entropy could probably be abstracted away to a more condensed representation (which could be then intelligently suggested based on semantics rather than syntax).

In other words, I think the approach assumes that the probability of the next word, based on syntax, is similar to probability of the next word, based on semantics, but I don't believe that's the case in programming languages.

That's a red herring. The "Eliza effect" has nothing to do with how toy-like ELIZA actual was, it is a lesson about how humans were very bad at evaluating its actual capability and insight. This continues to be true today, and is an effect with at least some impact on essentially any AI/ML system that people interact with.

I think the current "AI" models will never understand a thing unless they become able to update their own models and have some guiding logic to them. Sure it has the context tokens so it might give a little illusion of following along, but the randomness of it all also means it will get wrong stuff that it got right before (and vice versa) and will clearly break the illusion when prodded ("pikachu is a purple dragon", "The Wall was composed by Metallica"). It's unfortunate.

GPT3 and other text models have no sense of state. You can have the same instance work with 2 (or more) different persons and text provided by user A will have no bearing on anything user B does, since it's just trying to complete the provided text in form of tokens. As computationally intensive as it is, the whole thing is a lot simpler than it seems.

It's like we managed to get the "learning" part of intelligence more or less right, but nothing else yet. I always wanted to have an AI "trusted assistant" kinda thing, but even the biggest GPT3 models don't give me much in terms of trust. Wouldn't trust it to turn a lamp on and off as it is. (I know GPT3 is just a text model but you know what I mean). And if it happens, it won't be run locally because the hardware requisites for this stuff are obscene on a good day, which opens a few cans of worms (some of which have been opened already).

*useless as in getting anywhere close to intelligence. It can become decent entertainment and might have some interesting uses to correlate datum A to datum B/C/D, recognition and so, but so far it's just fancy ELIZA. An "educated guess engine" at best.

Did Ruby on Rails increase or decrease demand for web developers?

Did C increase or decrease demand for systems programmers?

Automation and abstraction is a complement, not a substitute.

If CoPilot works and we get to focus on higher level goals and developer throughout increases, it will be good for developers and good for the world. I hope CoPilot succeeds.

If copilot replaces anything, it will be the legion of failed developers that end up working for Oracle and Comcast currently doing god-knows-what with all their time. Those systems are already giant festering mounds of technical debt; imagine how bad it will get when literally no human has ever seen the code producing that weird bug.

It is about copilot (which it sneakily doesn’t mention by name) and tabnine and also generally about gpt-3 used in the realm of coding. A lot of layperson-oriented phrasing around: “ Microsoft, an American software giant, released a new version of an AI-completion feature which it embeds in coding software called Visual Studio.”

"AI programmer: autonomously creating software programs using genetic algorithms"

https://dl.acm.org/doi/10.1145/3449726.3463125

This particular program included if/then conditionals, counting down in a loop, concatenation of a numeric value with text, and displaying output.

The system also attempts to optimize the number of programming instructions executed, in which case complexity can actually be considered based upon the resulting behavior, rather than LOC.

I don't think we're ever going to get a GA to produce an air-traffic control system, or a database, or an OS. But 300 lines (that work) is further than I was aware had been possible.

(When I said "decent" in the first paragraph, that sounds like I'm damning it with faint praise. And I kind of am. But I am doing so in light of the Linux kernel, which is something like 100 million lines. I am not doing so to minimize this as an achievement within the world of GA-generated code. I'm just saying that we're a ways from being able to handle most real-world problems with GA-generated code.)

No matter how "smart" the implementation process is, we have the principle of "GIGO" (Garbage In; Garbage Out). Automated implementation has the potential to be a garbage multiplier.

There will always be a need for highly specific, accurate and detailed specifications. If a machine does the work, and makes assumptions, then that means the input needs to be of even higher quality than we see nowadays (See "GIGO," above).

I see the evolution of "Requirement Specification Languages," which, I suspect, will look an awful lot like code.

With programming, solutions aren't physically quantized except in the sense sufficiently skilled person hasn't run into an articulation of problem and solution they can actually understand yet.

Programmers aren't an odd bunch. We just like writing encyclopedias that people can read, understand, and build off of so someone can find something cool to do with it.

There's just a point where as system appreciating people, we can see where our own work is obviated or worked against if you just toss it at a machine that mangled it in such a way where the underlying ideas and knowledge is lost.

Which is funny when you think about it, but it does seem like it's headed in that direction.

coding is only a fraction of SWEing, sure Copilot writes some code for you - but can it work with stakeholders, manage the complexity of a complicated code base, or any other part of a engineer's job

This article uses the phrase "Automating Programming", but that phrase is not new. The term "Automatic Programming" was coined in 1958 by John Backus, and he was referring to his FORTRAN compiler.

Think about the tens of billions of humans who could have been employed writing Assembly over the past half century if we hadn't invented high-level programming languages.

What happens to programmers? They move up the abstraction ladder and tackle bigger problems, faster. Some people get left behind, sure. But then, ask the operators of punchcard machines how life is going. So maybe the "learn Python+HTML+JS in six months and become employable" status quo evaporates. But for at least another century there will always plenty of work for clever problem solvers who know how to tell computers to do things.

(FWIW, I'm not a programmer and haven't been employed as one since I was in school as an undergraduate, but I do I employ/manage a fair amount of people who program.)

We would do 3x the projects we're doing now, and salaries would go up as well as hiring.

Just wonder, how much does Intellicode actually save? Anyone has any experience?

My own take is that the saving probably isn't going to be significant, and will never be so. Because the bottleneck of programming is never caused by the speed of typing, but by the speed of thinking.

Kind of like Turnitin, but for code. It would check similarity, and check the licence of the similar code.

Implementation follows design.

I can't imagine machine 'intelligence' carrying out the former any time soon. When it does, we're done for anyway.

Two more papers down the line.

Here's a GPT-3 generated manual for a "flux capacitor".[1] It's a fun read, but meaningless. When the output text needs to integrate a collection of hard facts, GPT-3 is not helpful.

[1] https://archive.is/lQFHC