Hacker News Reader

Comment by _fat_santa | Hacker News Reader

I think the use case for Copilot is a bit misunderstood. The way I see it you have two types of code:

1. Smart Code: Code that you honestly have to think about while you're writing. You write this code slowly and carefully, to make sure that it does what you need it to

2. Dumb Code: This is trivial code, like adding a button to a screen. This is code you really don't have to think about, because you already know exactly how to implement it. At this point your biggest obstacle is how fast can your fingers type on a keyboard.

For me Github Copilot is useless for "Smart Code" but a godsend when writing "Dumb Code". I want to focus more on writing and figuring out the "Smart Code", if I need to throw a form together in HTML or make a trivial helper function, I will gladly let AI take over and do that work for me.

View on HN

> This is trivial code, like adding a button to a screen.

UX is probably the most important aspect of most software products. Every software product is either "smart code" or "smart ux". No one pays much for "dumb code with bad UX" except in dysfunctional markets.

Adding a button to a screen should be trivial, and if it's not you need better tools. (As in "a not-horribly-misdesigned language and framework", not as in "giant transformer".)

Deciding where to add the button, its shape, its size, what happens when it's clicked, the text on the button, ... is anything but trivial.

And once you decide all that, you still have to write:

    <Button ...

or whatever.

Code should be 90% thinking and 10% typing. I don’t need to over optimize the typing part

Yeah well until I get that job I suppose I'll just keep typing.

I'm mostly curious how much overlap there is in use cases for Snippets with parameters, possibly even snippets with conditional parameters vs Copilot.

I imagine there's some situations where Snippets do better, and where Copilot does better, but the more complex the situation the less i trust Snippets... but _also_ the less i trust Copilot.

It seems my trust in Copilot is very similar to that of use cases for Snippets. To throw out fake numbers, it makes me feel like Snippets (and tools like them) cover ~%70 of Copilot's use case. So i'm really curious on knowing what that %30 is, and if it is ever useful.

Yes I agree, I don't use a snippets feature/plugin, but that's what I thought of when it launched - 'why wouldn't I just'.

I suppose there's a (supposed) advantage that it's automatically finding and suggesting the snippet for you, rather than relying on you to think of it and recall the key binding, or know that it's there to such for.

Do you actually, though? I don't type out much HTML these days.

But everyone does pay for dumb code. Even in the best-written and most efficient codebases, there's still going to be some amount of tedious glue code and boilerplate that you have to write in order to create a functioning product. It definitely would be better to have better languages and frameworks instead of a giant transformer, but the better languages and frameworks don't exist yet while the giant transformer does.

> there's still going to be some amount of tedious glue code and boilerplate that you have to write in order to create a functioning product.

This is true, but actually tedious glue code is often non-trivial. For example, in one of my hobby projects I have a repo where I have to write a lot of glue code to schlepp data from a CSV file format into an existing database. Doing this correctly requires reading through the (lengthy) documentation for the format of both the CSV data and also the system that ingests the database, since there are a bunch invariants about the key tables and columns that aren't enforceable in SQL (and obviously not enforceable in the CSV).

This is the sort of glue code/boilerplate where a synthesizer that can understand natural language would be actually helpful.

> but the better languages and frameworks don't exist yet

There are certainly some languages that are less verbose than others.

Java and Go are very boilerplate-y languages. Python is also pretty verbose and inexpressive for certain types of code.

The typescript example on the copilot page right now is a prefect example of "ugh just use a better language".

The examples of boilerplate where copilot shines seem like situations where really simply using "snippets" would work better. E.g., everything on the copilot homepage right now.

>Java and Go are very boilerplate-y languages.

And because of the nature of boilerplate, Java has IDEs that will both generate and modify this boilerplate without thought, no AI required.

I don't remember the last time I typed the text 'class' for example. Instead I type "new Foo(someStringVar)", and then hit Alt-Enter and my IDE creates the file, the `class Foo` along with a ctor that takes a String.

Even in different versions of the same project, the glue may change. E.g. my boilerplate functions for making ajax calls have changed half a dozen times since 2005, been gutted and rewritten to be promosified, upgrade to websockets, and all sorts of other options, but I still have projects deployed that use several previous versions. And my typical PHP or Node executor has evolved, too. I myself find it confusing when working new bits into older projects where I'll occasionally match the wrong gateway code with the wrong frontend.

In other words, a machine looking at only my own glue would be more likely to mismatch or use the wrong version in any given situation.

This is basically the same argument that was made against required boiler plate in Java. “Your IDE can just generate that for you!” (And in sufficiently advanced cases, also keep ik it up to date.)

Imho, it is just an argument for making better languages and libraries. (These libraries will also make it easier to use with copilot.)

Exactly. The reason we aren't all sitting around hand-writing assembler is that programmers look at tedious processes and find higher-level abstractions that allow us to do more work in less time.

Once we spot a tedious common pattern, we should be finding ways to DRY it up. Configs, libraries, frameworks, DSL, tools, and languages are all great ways to do that. Copy-pasting and machine-generating code are short-term thinking in two ways: they focus on the initial creation of the code at the expense of maintenance, and they give up on increasing abstraction, lock the system into a productivity plateau.

You still have to describe to co-pilot what you want. So that doesn't make much sense. You should work on a higher level of abstraction then. If you aren't, why not spend a few minutes writing some functions instead of generating tons of unmaintainable boilerplate with co-pilot?

The code for a 'button type code' is trivial. Most what we used to call wizards handles that bit.

It is what the action of that button is where the real fun comes in.

I once had a project that was a yes/no dialog. Two buttons and some text. I had the dialog up and running in under an hour. The action that happened when you pressed yes took 3 months to finish.

I think you just described which coders will be replaced by AI first

Or you're describing how you could put copilot in a box and make a really good low code gui programming solution where the complex stuff is good old complex code.

It sounds like you're talking about a way to cut my front-end hiring budget by 80%.

I don't know, we somehow manage to replace point-and-click GUIs for placing buttons (Windows Forms etc) with Frontend developers writing elaborate code to achieve the same result in HTML/CSS. Productivity is far from the first priority for frontend development.

Idk I think it's not as easy to achieve a good front-end with point-and-click as you describe. When you have to do things like adaptive layouts, it seems like code actually manages a bit better than a WYSIWYG. Or there is some point of complexity where you need so many configuration options in a point-and-click editor that the code becomes easier to manage.

And the code is better for version control and review.

It's not that, it's that when you eventually reach the point where you need to do something that can't be handled by the WYSIWYG editor, you're left with 50,000 lines of shitty machine generated code that's almost impossible to work with.

The risk with WYSIWYG editors isn't that there's some tipping point where it becomes 10% more efficient to write code and you lose a bit of productivity or something. It's that something comes up half way through development and the WYSIWYG doesn't have the feature you need[1], and the entire project slams into a brick wall and dies instantly.

You can prevent this by running into the exact same problem CoPilot has, which is that reading code is harder than writing it. If you try to avoid the brick wall by having devs familiarise themselves with the code as the WYSIWYG generates it, those devs would have just been able to build it themselves in less time and with cleaner code.

[1] which will always happen eventually, because they're balancing the feature set for the exact reasons you mentioned. If they can do everything code can then the UX is going to be so bloated and horrible that it'd be trivially worse to use than just writing code.

Did autocomplete replace any coders?

If not, why should copilot?

The problem is you still have to go back and read through the "dumb code" to make sure it was written correctly. At a certain point, is that actually faster than just writing it yourself? Maybe a little bit, for some people and for some usecases, but it becomes a much narrower value-proposition.

Personally, I'd rather use snippets or some form of "dumb" code generation over an AI to generate the "dumb code". Sure, I'll probably still have to do some typing using those methods, but it's still less than if I were doing it all by hand.

It's not clear to me how that's better than the traditional solution to generate "Dumb Code", copy-pasting something. And we all know the problems with copy-pasting as a lifestyle.

Yes! Why is everyone so negative about copilot? I think it's a great name for the product. It helps you write, it doesn't write for you. You're still in charge and it can't write the "smart code".

Generally, a copilot is someone you can trust. The whole point of having a copilot is to reduce my cognitive load. If I am a pilot and have my copilot fly the plane while I do something else, I may be in charge, but I trust him to fly safely and alert me if things go wrong. A copilot is also a licensed pilot, able to do almost everything the pilot does, he is just not in charge.

The article shows that I can't trust GitHub copilot. So I don't think it is a representative name. Here, it would be more like a servant.

I love servants!

Reply on news.ycombinator.com