[blueappconfig]

from the original tweet linked in the post "ceiling is being raised. cursor's copilot helped us write "superhuman code" for a critical feature. We can read this code, but VERY few engineers out there could write it from scratch."

I don't really agree that code is superhuman if VERY few is able to understand it haha..! Code should complex but easy to follow to make it brilliant in my opinion

[Octoth0rpe]

I think Kernighan said something along the lines of "Because debugging code is twice as hard as writing it, only write code half as smart as you are or you'll never be able to fix it later". AI-assisted code generators seems to make this problem much worse as I can now write code 2x, or 3x as smart as I am. What hope will there ever be in debugging this?

A more optimistic take is that maybe such tools will let us write competent code in languages we do NOT specialize in, and in the future either a more competent version of ourselves or some actual expert can fix it if it breaks? That doesn't sound a whole lot better :/

[hobs]

The optimistic take is a feedback loop that makes them both better and more capable, writing code you can't debug is bad, but it could help you understand and build your own skills to a point that you can.

The pessimistic and more likely outcome is that people just want shit done and so they will slap any half working garbo together as they have done for the last 20 years I have been in the industry.

[AnimalMuppet]

And AI-assisted code is almost certainly code that AI can't debug...

[ozim]

What if I told you that one can write code again from scratch instead of fixing broken one?

Writing replaceable code instead of maintainable code seems to be already working for a lot of projects. With LLMs and all that fast computing we have it seems it will be more of replaceable code in the future.

Of course there are always projects where it will never work.

It already works for infrastructure as nowadays servers are not fixed and treated like important things but you spin up fresh one.

[rezonant]

> Writing replaceable code instead of maintainable code seems to be already working for a lot of projects.

I contend that these two concepts aren't different. If you have the ability to easily replace a small part of the code and have everything still work, then that's very maintainable. Unless you are talking about throwing out the whole codebase and replacing it, which for sufficiently complex codebases will inevitably lead to the second system effect. If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount.

> It already works for infrastructure as nowadays servers are not fixed and treated like important things but you spin up fresh one.

For that metaphor to work, the programmer would have to be patching the binary output instead of fixing the source code and recompiling.

[ozim]

> If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount.

Yes I think even as far as 70%-80% of code - IMHO - is not complex/valuable.

Most of code is replaceable CRUD not controls systems for flying and landing Falcon 9. So it is people problem not a technical problem, people pretend that they need "button more to the left and different shade" just to feel more important. Where we end up with loads of systems that do slightly different thing.

[rezonant]

This is a very extreme take to something far more nuanced... It's possible for code to be complex and valuable without meeting the extremes of "is a literal rocket control system" and "is some buttons on a form".

When I say valuable, I mean provides value to a business. When I say complex, I mean not buttons on a form.

[mumblemumble]

You spin up a fresh server from a cookie cutter image that lets you create a practically unlimited number of identical servers.

That's not even remotely like how rewriting code works. Rewriting code is more comparable to what spinning up a fresh server was like a quarter century ago. So, back in the days where they were important things because spinning up a new one was an unholy PITA and literally never went off without a hitch.

[jameshart]

That’s not the claim. It’s well commented and formatted so actually quite readable. The claim is that very few could write it.

Though I would say that ‘very few’ is a larger group than they think - there are plenty of people doing metatype programming in TS; I’ve dabbled enough that given the problem I could probably tackle it and I know I learned from seeing others do it (because I am far from a typescript professional). So it’s not ‘superhuman’ if many of the humans who have found themselves wanting to work with the typescript type derivation model could have written it.

These capabilities - type ternaries and inferred type parameters - were put into TypeScript with a view that humans would use them.

The danger here is kidding yourself that this sort of code is beyond human.

[UncleMeat]

I don't think that this is well commented. It explains what each line does, but it does not explain the overall technique being applied here and what it achieves. "Ah, if the parameter is optional I include undefined" is not useful. Instead what this wants is a block comment at the top explaining what this type achieves, how it should be used, and the strategy employed to construct this type.

[michaelt]

> It’s well commented and formatted so actually quite readable.

Are you looking at the same code I'm looking at? The first block of code from the article?

I've seen more readable code in Perl Golf competitions.

[jameshart]

That’s just how type programming looks.

Here’s (https://github.com/unional/type-plus/blob/main/packages/type...) a human written example that’s well-factored and uses loads of subtypes to clarify what it’s doing - but it’s still going to read like the black tongue of Mordor to you if you’re not familiar with how this kind of type stuff is structured and used.

And factoring all that stuff out may help readability but it doesn’t help comprehension - try and trace what the actual underlying type definitions for some of those utility types like IdentityEqual<> are actually doing (look at https://github.com/unional/type-plus/blob/main/packages/type...) and realize the rabbit hole runs deep in this stuff.

[michaelt]

The fact that unclear code is common does not make it clear.

Single-letter variable names, ternary operators and long run-on lines, like salt, are delicious in small quantities. But when you're writing code so complicated you need multiple comments, within a single statement?

I appreciate that you've got to piss with the cock you've got. I've certainly done things with C++ template metaprogramming, with perl, with TLA+ and with bash that I'm not proud of. But the fact the tool forces me to write something unclear doesn't mean I'm not writing something unclear.

[hwayne]

Can I ask more about the TLA+ spaghetti you had to write?

[michaelt]

In the defence of TLA+ I was a complete newbie.

I mention it only because certain parts of the experience shared the maths-looking big-sequence-of-ands-and-ors one sometimes sees when dealing with complex type systems. TLA+, very sensibly, lets you break up complex statements into multiple smaller statements and give them names.

I was simulating the behaviour of two ends of a communication channel which had been designed with a bidirectional message number/acknowledge/timeout/resend mechanism. And both a hardware and a software state machine on each end managing the message queue in each direction.

The experience was in equal parts brilliant and frustrating. Brilliant because it did reveal faults in the design that probably couldn't have been found any other way. Frustrating because (for example) if you represent your timeout mechanism as a counter on each end of the link and which can only count from 0 to 2 the check will succeed in a few seconds. But if you change the timeout behaviour to count from 0 to 10 the check will take a lot longer. I don't know exactly how long because I aborted the run after a week. And there was no real indication of precisely why it'd stopped completing - I basically had to undo my changes one line at a time until I figured out what was going on.

TLA+ also seemed to have some sort of TeX integration. So a lot of the documentation is written in TeX - it's a fine way of writing math I'm sure. But sometimes the documentation told you how to do something and showed an example statement with a dot, yet you couldn't copy-and-paste the example from the documentation into your code, to express it in your source code you had to use something like \cdot or \circ instead.

Interesting stuff to try out for sure. And impressive given the size of the team that works on it, which I gather is tiny.

[yxhuvud]

> That’s just how type programming looks.

Then that is an argument to do less of it. Or at least to back off and learn to write better types that are not a mess.

[awkward]

TS type formatting is an unpleasant language to write in, but it’s touring complete and not that different from C++ type formatting. Writing complex statements in it is just like complex statements in any language - break it down to understandable parts and build those up.

[zarzavat]

Even an average programmer can understand it if they bothered to read the TypeScript documentation. “Superhuman” in this case means “has read the manual”.

[frou_dh]

That's also how you become an extreme outlier at Bash. Actually read the manual.

[abathur]

My favorite kind of manual to actually read is sprinkled with hijinks-enabling arcana, and the Bash manual doesn't disappoint on this front.

[throwaway11460]

I read hundreds of the funny chat logs!

[blueappconfig]

No average person would be happy if they saw that mess

[nertirs]

Seems like the tweet is another AI hype pr piece. Since Devin was making outlandish statements, CoPilot can't fall far behind.

[janikvonrotz]

I agree! This is not superhuman code, this is machine code.

[shiandow]

Technically they're saying they can read it but wouldn't be able to come up with it on their own.

Which is impressive, generally reading code is considered harder than reading it so in that sense it is inhuman.