I mostly work with data mining on my personal projects(which is a couple of hours every day), and I'm pretty sure I didn't have to write a single regex since I've started using Copilot. It's hard for me to even imagine how I used to do it before, and how much time I've wasted on stupid mistakes and typos. Now I just write a comment of what I want and an example string. It does the job without me having to modify anything 99% of the time, even for complex stuff. Sure, sometimes it gives an overly complicated solution but it almost always works. Exciting times.

How do you know the regular expressions are correct, without understanding them?

I never said anything about not understanding them. If it's something simple, like getting a date from a string, a quick glance will tell me if it'll work. If it's more complex, a quick glance or two will give me the general idea and then I can test it against what I think will be edge cases. If you don't know what kind of a string you'll have to process then you can't really know if any regex is correct, and if you do testing it in most cases is pretty easy and quick. You'd have to test even if you write it yourself. And in the cases where it's wrong it usually gives me a good starting point.

All regular expressions are incorrect, but some are useful.

(It's a reference)

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

Who cares if they're correct? If they fail a test, you can fix them. If they turn out to be wrong in production you can isolate the example and add it as a test. Producing regexes that pass all current tests but contain a subtle bug satisfy 100% of what programmers are incentivized to do. Producing them very quickly will get you promoted.

I think we will very soon start seeing a clear separation between programmers ("co-pilot operators") and software engineers (those who do the thinking and understanding when there's someone "who cares").

We already have that bifurcation in the sense that the majority of programmers can use frameworks, libraries, etc. to get work done but don't have the deeper knowledge to build them well.

This separation has existed since the first computer was built.

I feel like you only see programmers as cogs, and not programmers as invested in the success of their product with the statement like "satisfy 100% of what programmers are incentivized to do"

Generally the people using regexes care if they're correct. Frequently, all possible input variants are not enumerated in tests. Frequently, companies want to have confidence in their production code. Imagine this regex is deployed on a sign up flow, and its failures invisibly increase your churn rate. Can it happen with a hand crafted regex? Yes, of course. But I'd imagine it will happen even more frequently with an AI produced custom regex plus a person who doesn't actually understand regexes.

Programmers often feel invested in the success of their product but that's not what they're incentivized to do. They're incentivized to produce fast results that are bad in ways that you have to be a programmer to understand.

If you have to be a programmer to understand why something's bad, who's going to prevent it? This is a major unsolved problem in the structure and organization of working.

The CTO who used to be a dev. More generally anyone in management with a technical background. They may not exist in some companies, but that's not because it's "a major unsolved problem in the structure and organization of working", it's because the company sucks in that regard.

Except testers and users aren’t programmers. Code reviews are what’s supposed to catch this stuff, but it’s rare for a team lead or other programmer to investigate every single commit.

You're not wrong, but hopefully someone is at least doing a code review.

Thanks for the good example. The first time I tried OpenAI's assistant (before I had access to GitHub CoPilot) I wrote a comment in Javascript code that read something like "perform SPARQL query to find out where Bill Gates works" and code was generated using an appropriate library, the SPARQL (like SQL) query was correct, and the code worked. Blew my mind.

would like to talk about the paintpoints you experienced while doing data preparation and mining

I have an e-mail in my description, you can ask me what you'd like to know there.

Could you say a bit more about how you use CoPilot? What are the "other tools" you use?

I installed the VSCode and PyCharm CoPilot plugins, and signed in with my GitHub account (you first need to request CoPilot access and wait until you get it).

As you type in comments or code, CoPilot will sometime autocomplete up to about 10 lines of code, based on the content of the file you are editing (maybe just the code close to the edit point?).

My other tools? I use LispWorks Professional, Emacs with Haskell support, and sometimes IntelliJ. I work a lot on remote servers so I depend on SSH/Mosh and tmux also.

Do you usually find the autocomplete from CoPilot useful enough to keep without editing, or is it wrong often enough to be annoying?

In my opinion it's wrong most of the time but it's so harmless that it's absolutely worth it for the times it's right.

Kind of like regular autocomplete. If it's wrong you just keep typing.

If it is wrong, I hit the escape key and the suggested code disappears.

For me both are true. The suggestions are usually annoying and wrong, however sometimes copilot makes an observation that is non-obvious, i.e it suggests code that makes me realize that I was about to write a subtle bug. I keep it on as a sanity check.

We're not seeing exponential rates of progress, in my opinion.

We've been on the steep part of an S-curve.

When you're on that curve, it's indistinguishable until you hit the plateau. We're in an era where AI is continuing to improve and has already surpassed a level that many people doubted was achievable. Nobody knows when that progress will plateau. It's entirely possible that we plateau _after_ surpassing human-level intelligence.

If you have actual data you can take the derivative of the curve and see you're on the S curve with a lot of confidence by the time you hit the middle and long before the plateau: https://miro.medium.com/max/700/1*6A3A_rt4YmumHusvTvVTxw.png

Even small errors in measurement will greatly change the location of the projected plateau so this is not usually useful in practice.

Exactly correct. We really don't know if the progress is exponential or like a Sigmoid squashing function. You just changed my opinion, a bit, on this.

If we're limited to Earth and fossil fuels, then it's a sigmoid.

The AI technology today has practical value for some use cases but it's basically just clever parlor tricks. There has been near zero discernable progress toward artificial general intelligence. We don't yet have a computer that can learn and make optimal resource usage decisions in an open world environment as well as a mouse. In most respects we're not even at the insect level yet.

You're making the point that the linked article is trying to argue against.

How good is this model at fighting other insects?

> The AI technology today has practical value for some use cases but it's basically just clever parlor tricks.

Come on, you could have said the same thing about excel 30 years ago.

Yes Excel has more features today. So what? We're still not making any measurable progress towards true AGI. We don't even know what the development path or ultimate goal looks like except for some vague hand waving about passing the Turing Test.

I work for a company that provides "ai" services in a "boring" domain. The Time saved and accuracy (for a legally audited result) we provide is quantifiable, and when I saw the numbers I was surprised. So while a lot of the "AI" hype is stupid marketing bs, some of us are actually doing real stuff, it's not just parlor tricks. You might also be surprised in how many domains a small improvement has huge yield in terms of raw money and/or quality of life improvements.

The steep part of a sigmoid curve DOES grow almost exponentially though. What's the point of saying this? It's like saying, "sure we are making great progress, but eventually the universe will come to an end and we'll all be dead." Who cares? Why not worry about that when we're there?

The point is that it is a completely different framework to think about the future.

The exponential model is something close than what is behind Ray Kurzweil reasoning about the Great Singularity and how the future will be completely different and we're all going to be gods or immortals or doomed or something dramatic in that vein.

The S-Curve is more boring, it means that the future of computing technology might not be that mind blowing after all, we might already have reaped most of the low-hanging fruits.

A bit like airplanes, or space tech you know, have you seen those improving by a 10x factor recently?

>A bit like airplanes, or space tech you know, have you seen those improving by a 10x factor recently?

Is space tech included ironically here? There's been 10x (or more) improvements across dozens of space tech problems in the last couple decades.

Could we send people on the Moon if we wanted? We might but I am honestly not completely sure.

Would that be 1000x, 100x or even 10x easier than 60 years ago? Well, I don't think so.

From my perspective space tech has never quite leaved the prototype phase, for some reason.

No one knows the future for sure. But with current trend of dividing the world again, I would agree on your assumption.

But I still have hope for a undivided world, that one day even abolish the patent system. Then I would see potential for exponentional progress.

100% this. Exponential progress is only a thing if potential progress is infinite. If the potential progress is finite (hint: it is), eventually the rate of progress hit progressively diminishing returns.

What is the limit you foresee on computation, especially when such computations can optimise themselves without human intervention?

The underlying rule here, in my opinion, is the law of diminishing returns. (log shaped curve)

AlphaZero is already capable of optimizing itself in the limited problem space of Chess.

Infinitely increasing the computing power of this system won't give it properties it does not already have, there is no singularity point to be found ahead.

And I am not sure that there are any singularities lying ahead in any other domains with the current approach of ML/AI.

And building on that, the real bottleneck in most domains isn't going to be computer power, it's going to be human understanding of how to curate data or tweak parameters.

We've already seen in games with simple rules and win conditions that giving computers data on what we think are good human games can make them perform worse than not giving them data. Most problems aren't possible for humans to ebncapsulate perfectly in a set of rules and win conditions to just leave the processing power to fill in the details, and whilst curating data and calibrating learning processes is an area we've improved hugely on to get where we are with ML, it's not something where human knowledge seems more likely to reach an inflection point than hit diminishing returns.

We've seen with ML and Chess (an go to some extent) that brute forcing the problem space is clever than using heuristics.

I think this is only true because, so far, our heuristics are not that clever.

But, godlike though the human variants may appear to be, what happens when the system reaches the skill level of an above-average software architect?

There are physical limits to computation.

The number of orders of magnitude remaining, is not that large.

There is no such thing as truly unbounded exponential growth, it's always an S curve