Not the one I want. I'd like to see better theorem proving, proof repair, refinement and specification synthesis.

It's not generating code that seems to be the difficulty, it's generating the correct code. We need to be able to write better specifications and have our implementations verified to be correct with respect to them. The future I want is one where the specification/proof/code are shipped together.

Also, it's not actually writing the code that is the difficulty when generating code changes for maintaining existing code, but figuring out what changes need to be made to add up to the desired feature, and where in the codebase controls each of those, and possibly rediscovering important related invariants.

For that matter, the really critical part of implementing a feature isn't implementing the feature -- it's deciding exactly what feature if any needs to be built! Even if many organizations try to split that among people who do and don't have the title of programmer (eg business analyst, product manager...), it's fundamentally programming and once you have a complex enough plan, even pushing around and working on the written English feature requirements resembles programming with some of the same tradeoffs. And we all know the nature of the job is that even the lowliest line programmer in the strictest agile process will still end up having to do some decision making about small details that end up impacting the user.

Copilot is soooooo far away from even attempting to help with any of this, and the part it's starting with is not likely to resemble any of the other problems or contribute in any way to solving them. It's just the only part that might be at all tractable at the moment.

As interesting as those systems may be, they have it exactly backwards. Don't let the computer generate code and have the human check it for correctness: let the human write code and have the computer check it for correctness.

The human also needs to make sure the code does what the Ticket asked for. And sometimes not even what the Ticket asked for, but what the business and user want/need.

Honestly writing code is such a small part of a dev's job. It's figuring out how to translate the human (often non-tech) requirements into code that is also in a way that's also looking at requests that haven't been made yet.

Isn't that pretty much what ML does?

> ... I will not delve into the questions of code quality, security, legal & privacy issues, pricing, and others of similar character. ... Let’s just assume all this is sorted out and see what happens next.

Honestly, it seems pretty dangerous. Seemingly correct code generated by a neural network that we think probably understands your code but may not. Easy to just autocomplete everything, accept the code as valid because it compiles, and discover problems at run-time.

Formal methods and theorem proving on the other hand, place a strong emphasis on proof production and verification.

Instead, they decided to waste their work on that.

AWS has ML driven code analysis tools in their "CodeGuru" suite: https://aws.amazon.com/codeguru/

More often than not, once I have the tests written, the code nearly writes itself. There are edge cases when I have to look up things, but most of the time it's I'm happily TDD'ing.

A couple of years ago, we invested in using the libraries from Microsoft Code Contracts for a couple of projects. It was a really promising and interesting project. With the libraries you could follow the design-by-contract paradigm in your C# code. So you could specify pre-conditions, post-conditions and invariants. When the code was compiled you could configure the compiler to generate or not generate code for these. And next to the support for the compiler, the pre- and post-conditions and invariants were also explicitly listed in the code documentation, and there was also a static analyzer that gave some hints/warnings or reported inconsistencies at compile-time. This was a project from a research team at Microsoft and we were aware of that (and that the libraries were not officially supported), but still sad to see it go. The code was made open-source, but was never really actively maintained. [0]

Next to that, there is also the static analysis from JetBrains (ReSharper, Rider): you can use code annotations that are recognized by the IDE. It can be used for (simple) null/not-null analysis, but also more advanced stuff like indicating that a helper method returns null when its input is null (see the contract annotation). The IDE uses static analysis and then gives hints on where you can simplify code because you added null checks that are not needed, or where you should add a null-check and forgot it. I've noticed several times that this really helps and makes my code better and more stable. And I also noticed in code reviews bugs due to people ignoring warnings from this kind of analysis.

And finally, in the Roslyn compiler, when you use nullable reference types, you get the null/not-null compile-time analysis.

I wish the tools would go a lot further than this...

[0] https://www.microsoft.com/en-us/research/project/code-contra... [1] https://www.jetbrains.com/help/resharper/Reference__Code_Ann...

Thanks for making me smile. Some of us are working on exactly that kind of thing :)

Something along lines of this perhaps...

https://www.fixtrading.org/standards/fix-orchestra/

For me, this is definitely a piece of the future of coding, and it doesn't change coding from a creative endeavour. It's just the difference between "let me spend five minutes googling this canvas API pattern I used 5 years ago and forgot, stumble through 6 blogs that are garbage, find one that's ok, ah right that's how it works. Now what was I doing?" To just writing some prompt comment like "// fn to draw an image on the canvas" and then being like "ah that's how it works. Tweak tweak write write". For me the creativity is in thinking up the high level code relationships, product decisions, etc. I don't find remembering random APIs or algos I've written a million times before to be creative.

Even bugs are acceptable if the advantages of auto generated code are large enough.

My concern is that ML code generation will create very shallow mental models of code in developers' minds. If everyone in the organization is building code this way, then who has the knowledge and skills to debug it? I foresee showstopping bugs from ML-generated that bring entire organizations to a grinding halt in the future. I remember back in the day when website generators were in vogue, it became a trend for many webdevs to call their sites "handmade" if they typed all the code themselves. I predict we'll be seeing the same in the future in other domains to contrast "handwritten" source with ML generated source.

What's that famous quote? "Debugging is twice as hard as writing the code in the first place." Well where does that leave us when you don't even have to write the code in the first place? I guess then we will have to turn to ML to handle that for us as well.

I think it’s more like WYSIWYG website generators (anyone remember Cold Fusion? The biz guys LOVED that - for like a year).

I think most companies' management would still leave decisions like that in the hands of developers/development-teams. At the level of management, I think companies aren't asking for "code" but for results (a website, an application, a feature). Results with blemishes or insecurities are fine but a stream of entirely broken code wouldn't be seen as cost effective.

The problem always comes later (often after the manager has moved on and is no longer aware of the mistakes that were made and the repercussions can't follow) where the maintenance costs of poorly written initial code come back to haunt the origination for years to come.

Which I personally suspect this will end up about as well as WYSIWYG HTML editors/site generators. Which do have a niche.

That would be the ‘makes a lot of cheap crap quickly, but no one uses it for anything serious or at scale’ niche.

Because what comes out the other end/under the hood is reprocessed garbage that only works properly in a very narrow set of circumstances.

I suspect with this market correction however we’ll see a decrease in perceived value for many of these tools, as dev pay is going to be going down (or stay the same despite inflation), and dev availability is going to go up.

That the monkey is actually a computer and not an actual banana eating primate doesn't change anything there.

Any business fool that tries this will discover this very quickly - that's like claiming we don't need drivers because we have cruise control in our cars! It is not perfect but it is cost effective/works (some of the time ...)!

Do it enough times, and I’m sure it will eventually compile - might even complete a regression test suite!

For application/x-www-form-urlencoded as shown, that’d be using URLSearchParams:

  fetch("https://text-processing.com/api/sentiment", {
      method: "POST",
      body: new URLSearchParams({ text }),
  })

  const body = new FormData();
  body.append("text", text);
  fetch("https://text-processing.com/api/sentiment", { method: "POST", body })

As a fun additional aside, you’ve made a tiny error in your transcription: the URL was actually surrounded in backticks (a template literal), not single quotation marks. Given the absence of a tag or placeholders (which would justify a template literal) and the use of double-quoted strings elsewhere, both of these would be curious choices that a style linter would be very likely to complain about. So yeah, just another small point where it’s generating weird code.

Yes, many companies prefer to hire them, or can only retain them for a variety of reasons. None of this is good in any way.

Anyway, those programmers have really good odds to stop creating this kind of code given some learning. While adding Copilot as a "peer" just makes them less likely to learn, and all programmers more likely to act like them. That's not matching the status-quo, that's a very real worsening of it.

Security holes are more excusable because someone who didn't realize the above could happen maybe never tested it... given the use case, this is more like "did you even run your code?"

I think it's because people copy/paste generated code without reading it carefully. They eyball it, it makes sense, they go tweet about it.

I don't know if this predicts how people will mostly use generated code. I note however that this is probably too much code to expect CoPilot to generate correctly: about 10 LoCs is too much for a system that can generate code, but can't check it for correctness of some sort. It's better to use it for small code snippets of a couple of lines, like loops and branches etc, than to ask it to genrate entire functions. The latter is asking for trouble.

These are the examples which GitHub itself uses to demonstrate what Copilot is capable of, so it's not just a matter of people tweeting without reading through the code properly. It also suggests that the people behind Copilot do believe that one primary use-case for Copilot is to generate entire functions.

Well, OpenAI are certainly trying to sell copilot as more capable than it is, or anyway they haven't done much to explain the limitations of their systems. But they're not alone in that. I can't think of many companies with a product they sell that tell you how you _can't_ use it.

Not to excuse misleading advertisment. On the contrary.

Maybe, in some organizations, sure. However, there are still people hand-crafting things in wood, metal, and other materials even though we have machines that can do almost anything. Maybe career programmers will turn into "ML debuggers", so perhaps all of us who enjoy building things ourselves will just stop working as programmers? I certainly won't work in the world where I'm just a "debugger" for machine-generated crap.

  function evil(code) {
      eval(code);
  }

  evil("alert('hi');");

Taking your comment as inspiration, I would like to add OWASP/Unit Testing thinking to Copilot. If Copilot considers your remarks and maybe others, it becomes helpful. Something like security checking on the fly, what would normally be considered by colleagues during code reviews or checks with SonaCube.

> Let’s just assume all this (code quality, security, legal & privacy issues, pricing, and others of similar character) is sorted out and see what happens next.

What could go wrong next in the systems where they employ this AI with this mindset?

Why? POST data doesn't need to be URL encoded.