Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enough AI copilots, we need AI HUDs

geoffreylitt.com

Post reply on HN
Print view View original

81–90 of 290 posts

Re: Enough AI copilots, we need AI HUDs

#81

Post by nextaccountic »

furyofantares wrote: post #68

I'm very curious if a toggle would be useful that would display a heatmap of a source file showing how surprising each token is to the model. Red tokens are more likely to be errors, bad names, or wrong comments.

Even if something is surprising just because it's a novel algorithm, it warrants better documentation - but commenting the code explaining how it works will make the code itself less surprising!

In short, it's probably possible (and it's maybe a good engineering practice) to structure the source such as no specific part is really surprising

It reminds me how LLMs finally made people to care about having good documentation - if not for other people, for the AIs to read and understand the system

Re: Enough AI copilots, we need AI HUDs

#83

Post by motorest »

ThunderSizzle wrote: post #35
JimDabell wrote: post #29

Earlier quoted context omitted.

> When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You don’t need to write tests for that, you need to write acceptance criteria.

As in, a developer would write something in e.g. gherkin, and AI would automatically create the matching unit tests and the production code? That would be interesting. Of course, gherkin tends to just be transpiled into generated code that is customized for the particular test, so I'm not sure how AI can really abstract it away too much.

> That would be interesting. Of course, gherkin tends to just be transpiled into generated code that is customized for the particular test, so I'm not sure how AI can really abstract it away too much.

I don't think that's how gherkin is used. Take for example Cucumber. Cucumber only uses it's feature files to specify which steps a test should execute, whereas steps are pretty vanilla JavaScript code.

In theory, nowadays all you need is a skeleton of your test project, including feature files specifying the scenarios you want to run, and prompt LLMs to fill in the steps required by your test scenarios.

You can also use a LLM to generate feature files, but if the goal is to specify requirements and have a test suite enforce them, implicitly the scenarios are the starting point.

Re: Enough AI copilots, we need AI HUDs

#84

Post by motorest »

JimDabell wrote: post #39
ThunderSizzle wrote: post #35

Earlier quoted context omitted.

As in, a developer would write something in e.g. gherkin, and AI would automatically create the matching unit tests and the production code? That would be interesting. Of course, gherkin tends to just be transpiled into generated code that is customized for the particular test, so I'm not sure how AI can really abstract it away too much.

I’m talking higher level than that. Think about the acceptance criteria you would put in a user story. I’m specifically responding to this: > When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You don’t need to personally write code that mechanically iterates over every possible state to remain in the driver’s seat. You need to desc…

> When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat.

You're describing the happy path of BDD-style testing frameworks.

Re: Enough AI copilots, we need AI HUDs

#85

Post by Kichererbsen »

nextaccountic wrote: post #81
furyofantares wrote: post #68

I'm very curious if a toggle would be useful that would display a heatmap of a source file showing how surprising each token is to the model. Red tokens are more likely to be errors, bad names, or wrong comments.

Even if something is surprising just because it's a novel algorithm, it warrants better documentation - but commenting the code explaining how it works will make the code itself less surprising! In short, it's probably possible (and it's maybe a good engineering practice) to structure the source such as no specific part is really surprising It reminds me how LLMs finally made people to care about having good document…

I often find myself leaving review comments on pull requests where I was surprised. I'll state as much: This surprised me - I was expecting XYZ at this point. Or I wasn't expecting X to be in charge of Y.

Re: Enough AI copilots, we need AI HUDs

#86

Post by motorest »

kamaal wrote: post #38
ThunderSizzle wrote: post #35

Earlier quoted context omitted.

As in, a developer would write something in e.g. gherkin, and AI would automatically create the matching unit tests and the production code? That would be interesting. Of course, gherkin tends to just be transpiled into generated code that is customized for the particular test, so I'm not sure how AI can really abstract it away too much.

All of this at the end reduces to a simple fact at the end of the discussion. You need some of way of precisely telling AI what to do. As it turns out there is only that much you can do with text. Come to think of it, you can write a whole book about a scenery, and yet 100 people will imagine it quite differently. And still that actual photograph would be totally different compared to the imagination of all those 100…

> You need some of way of precisely telling AI what to do.

I think this is the detail you are not getting quite right. The truth of the matter is that you don't need precision to get acceptable results, at least in 100% of the cases. As everything in software engineering, there is indeed "good enough".

Also worth noting, LLMs allow anyone to improve upon "good enough".

> As it turns out if you wish to describe something accurately enough, you have to write mathematical statements, in other words statements that reduce to true/false answers.

Not really. Nothing prevents you to refer to high-level sets of requirements. For example, if you tell a LLM "enforce Google's style guide", you don't have to concern yourself with how many spaces are in a tab. LLMs have been migrating towards instruction files and prompt files for a while, too.

Re: Enough AI copilots, we need AI HUDs

#87

Post by cadamsdotcom »

motorest wrote: post #75
cadamsdotcom wrote: post #4

Love the idea & spitballing ways to generalize to coding.. Thought experiment: as you write code, an LLM generates tests for it & the IDE runs those tests as you type, showing which ones are passing & failing, updating in real time. Imagine 10-100 tests that take The tests could appear in a separated panel next to your code, and pass/fail status in the gutter of that panel. As simple as red and green dots for tests t…

> Thought experiment: as you write code, an LLM generates tests for it & the IDE runs those tests as you type, showing which ones are passing & failing, updating in real time. Imagine 10-100 tests that take I think this is a bad approach. Tests enforce invariants, and they are exactly the type of code we don't want LLMs to touch willy-nilly. You want your tests to only change if you explicitly want them to, and even…

I think tests should be rewritten as much as needed. But to counter the invariant part, maybe let the user zoom back and forth through past revisions and pull in whatever they want to the current version, in case something important is deleted? And then allow “pinning” of some stuff so it can’t be changed? Would that solve for your concerns?

Re: Enough AI copilots, we need AI HUDs

#88

Post by JimDabell »

motorest wrote: post #84
JimDabell wrote: post #39

Earlier quoted context omitted.

I’m talking higher level than that. Think about the acceptance criteria you would put in a user story. I’m specifically responding to this: > When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You don’t need to personally write code that mechanically iterates over every possible state to remain in the driver’s seat. You need to desc…

> When you give up the work of deciding what the expected inputs and outputs of the code/program is you are no longer in the drivers seat. You're describing the happy path of BDD-style testing frameworks.

I know about BDD frameworks. I’m talking higher level than that.

Re: Enough AI copilots, we need AI HUDs

#89

Post by kn81198 »

About a decade back Bret Victor [1] talked about how his principle in life is to reduce the delay in feedback, and having faster iteration cycles not just helps in doing things (coding) better but also contributes to new creative insights. He had a bunch of examples built to showcase alternative ways of coding, which is very close to being HUDs - one example shown in the OP is very similar to the one he presents to "step through time to figure out the working of the code".

[1]: https://www.youtube.com/watch?v=PUv66718DII

Re: Enough AI copilots, we need AI HUDs

#90

Post by piker »

Absolutely agree, and spellchecker is a great analogy.

I've recently been snoozing co-pilot for hours at a time in VS Code because it’s adding a ton of latency to my keystrokes. Instead, it turns out that `rust_analyzer` is actually all that I need. Go-to definition and hover-over give me exactly what the article describes: extra senses.

Rust is straightforward, but the tricky part may be figuring out what additional “senses” are helpful in each domain. In that way, it seems like adding value with AI comes full circle to being a software design problem.

ChatGPT and Claude are great as assistants for strategizing problems, but even the typeahead value seems to me negligible in a large enough project. My experience with them as "coding agents" is generally that they fail miserably or are regurgitating some existing code base on a well known problem. But they are great at helping config things and as teachers in (the Socratic sense) to help you get up-to-speed with some technical issue.

The heads-up display is the thesis for Tritium[1], going back to its founding. Lawyers' time and attention (like fighter pilots') is critical but they're still required in the cockpit. And there's some argument they always will be.

[1] https://news.ycombinator.com/item?id=44256765 ("an all-in-one drafting cockpit")

Post reply on HN