ML code generation vs. coding by hand: what we think programming will look like

Okay but I can&#x27;t avoid noticing the bug in the copilot-generated code. The generated code is:<p><pre><code> async function isPositive(text: string): Promise&lt;boolean&gt; { const response = await fetch(&#x27;https:&#x2F;&#x2F;text-processing.com&#x2F;api&#x2F;sentiment&#x27;, { method: &quot;POST&quot;, body: `text=${text}`, headers: { &quot;Content-Type&quot;: &quot;application&#x2F;x-www-form-urlencoded&quot;, }, }); const json = await response.json(); return json.label === &quot;pos&quot;; } </code></pre> This code doesn&#x27;t escape the text, so if the text contains the letter &#x27;&amp;&#x27; or other characters with special meanings in form URL encoding, it will break. Moreover, these kinds of errors can cause serious security issues; probably not in this exact case, the worst an attacker could do is change the sentiment analysis language, but this class of bug in general is rife with security implications.<p>This isn&#x27;t the first time I&#x27;ve seen this kind of bug either -- and this class of bug is always shown by people trying to showcase how amazing Copilot is, so it seems like an inherent flaw. Is this really the future of programming? Is programming going to go from a creative endeavor to make the machine do what you want, to a job which mostly consists of reviewing and debugging auto-generated code?

Machine Learning algorithms are only as good as the data they are trained on.<p>For tasks like self-driving or spotting cancer in x-rays, they are producing novel result because these kinds of tasks are amenable to reinforcement. The algorithm crashed the car, or it didn&#x27;t. The patient had cancer, or they didn&#x27;t.<p>For tasks like reproducing visual images or reproducing text, it _seems_ like these algorithms are starting to get &quot;creative&quot;, but they are not. They are still just regurgitating versions of the data they&#x27;ve been fed. You will never see a truly new style or work of art from DALL-E, because DALL-E will never create something new. Only new flavors of something old or new flavors of the old relationships between old things.<p>Assuming that it is even possible to describe novel software engineering problems in a way that a machine could understand (i.e. in some complex structured data format), software engineering is still mostly a creative field. So software engineering isn&#x27;t going to performed by machine learning for the same reason that truly interesting novels or legitimately new musical styles won&#x27;t be created by machine learning.<p>Creating something new relies on genuine creativity and new ideas and these models can only make something &quot;new&quot; out of something old.

Trying to solve the lack of progress in simplifying the complexity of standard development scenarios needs to be the next step in framework development. I just don&#x27;t understand how or why it needs to be polluted by the unnecessary added hidden complexity of ML. You&#x27;re just shifting your unknowns into a black box and it&#x27;s magic output.

My work is 90% business and 10% code. I do not see how we can have AI writing useful code on its own without also understanding lots of context about human society.<p>When I code something out, I have to first know which problem to solve, and why it’s a problem. I then have to understand the problem in minute detail. This usually involves a slew of human factors, desires, and interfacing with idiosyncratic systems that evolved a certain way because of human factors and desires.

If we imagine that at some point in the future, the majority of code would be produced by ML code generation, then where will the training data for future ML models come from?<p>With the current way of ML code generation, it seems that there will always need to be a critical mass of coders who produce code on their own, to be able to serve as new input for the ML models, to be able to learn about new use cases, new APIs, new programming languages, and so on.<p>ML code generation may serve as a multiplier, but it raises questions about the creation and flow of new knowledge and best practices.

The problem with all of these arguments is we are just shooting in the dark.<p>The day before Copilot launched, if someone had told me code generation at the fairly decent quality Copilot achieves was already possible I probably wouldn&#x27;t believe it. I could happily rattle off a couple of arguments for why it might be better than autocomplete but could never write a full function. Then it did.<p>Who can say how far it&#x27;s come since then? I think only the Copilot team knows. I wish we could hear from them, or some ML experts who might know?

The problem with this is that, just like visual programming, it doesn’t really do the hard parts.<p>I remember hearing “a million monkeys with a million type writers writing for a million years could write Shakespeare”. Sure, but how would they know it? How could they recognize when they have achieved their goal?<p>ML will lower the bar for the trivial tedious things and let people believe they are more capable than they are. Even with ML you will have to know what to ask and what the answer should be. That is always the hard part.

I&#x27;ve been using a Copilot for a while. It&#x27;s neat, saves me some typing sometimes, but it&#x27;s not even remotely close to doing even a small portion of my work for me.

“Although ML code generation helps with getting the initial code written, it cannot do much beyond that - if that code is to be maintained and changed in the future (and if anyone uses the product, it is), the developer still needs to fully own and understand it.”<p>I think this is a misconception. It’s true for these first prototype code generation tools, but there’s no reason to think that in the future these models won’t be adapted to modify&#x2F;maintain code too.

The article presupposes that ML is only for code generation but not maintenance. Why couldn&#x27;t this change in the future? Perhaps you&#x27;d have an english language document that describes the functionality, and as you update it, the code gets re-generated or updated.

There&#x27;s only 2 options, either you train on the full mediocrity of Github, or you over-train on highly rated projects, effectively just copy&#x2F;pasting those projects and riding roughshod over any licensing the authors think they have. At least the mediocrity of the suggested code suggests they&#x27;re trying to do the former.

The momentum behind this whole thing feels strongly like a handwavy attempt to subvert the GPL and similar.

I think the biggest misconception with a lot of the comments here is that they are assuming that the code generated by copilot is final. Copilot, as the name suggests, is a human-in-the-loop system. It <i>requires</i> a developer to give it prompts and to massage the code it generates. It&#x27;s not intended to or will it ever feasibly be able to generate code entirely independently.<p>The point is that this massaging is a lot faster than writing everything from 0 in most cases. It doesn&#x27;t have to be bug free. It doesn&#x27;t have to be perfect quality. It doesn&#x27;t have to do &quot;the hard parts&quot; of coding. It just has to be good enough to be sufficiently faster for the developer than starting from 0, and it is.

I think it’s hard to view ML generated code as the future when you see how powerful type-driven development can be with the likes of Idris and others.<p>Perhaps the best approach could use ML within the constraints provided by a type system. Does research like this exist?

So far my most practical use of Copilot is prompting it with `&#x2F;&#x2F; Handle errors`.

Garbage in garbage out.

No, it&#x27;s still a terrible idea even if it&#x27;s used as an auto-complete. As the article correctly states, the primary job of a software engineer is to maintain existing code, not to write new code. You&#x27;re not going to be doing yourself any favors by committing code that you didn&#x27;t even read (unless you&#x27;re one of those people who can get away with shoving all your bugs onto coworkers, in which case you&#x27;re an asshole).

&gt; For the purposes of this post, I will not delve into the questions of code quality, security, legal &amp; privacy issues, pricing, and others of similar character that are often brought up in these early days of ML code generation. Let’s just assume all this is sorted out and see what happens next.<p>&quot;Let&#x27;s assume magic ponies exist, are commonplace and would love to give us all magic rainbow rides&quot;

It&#x27;s kind of sad that the future of programming isn&#x27;t more expressive languages. It&#x27;s auto-generating code in the languages we have.

AI coding is not constrained to javascript, which is a function of human knowledge inertia and hiring practices, all irrelevant to AI-assisted coding. Ideally syntax becomes a non issue and we can start valuing correctness and maximizing business leverage per LOC. However we don’t know how long the transition window will be. Everything is accelerating, so quickly I hope!

I think it is strongly likely that Copilot will be 1 million times better by the end of the decade. Increasing compute, new techniques, etc<p>The top comment on this post is complaining about a bug in Copilot generated code. 1 million times better Copilot won&#x27;t do that.

&gt;[...] thank you for your generous comments, ideas and suggestions! You made this post better and made sure I don&#x27;t go overboard with memes :).<p>Yeah man, I&#x27;m not sure about the latter. Not sure...

Wonder if anyone is working on using ML for machine code generation.

&gt; a huge win for the developer community<p>&gt; allows us to write even less code and care about fewer implementation details<p>Remember Bjarne Stroustrup: “I Did It For You All…”? More code, more complexity — more job security.