Hacker News Reader

Comment by mickeyp | Hacker News Reader

I find the value of someone steering an AI session to be practically nil for nearly everything. Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.

So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything.

No, the future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.

View on HN

> Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.

I think the issue that many may not want to think about is, how do we promote/reward/fire developers in the AI assisted programming age. As part of code reviews, I think it will be second nature to ask "how did you arrive at the code".

Can’t wait to get in trouble for having curse words in my chat with AI get flagged by the company’s anti-swearing-in-code automation.

I think it makes no sense to share the conversation but I do think developers will be required to provide lessons, notes and checkpoints in the conversation.

What I think will happen is you will be required to run the conversation through a company required prompt that will include things like, does the conversation contain "think harder" without providing any guidance for how to correct things.

Basically, did the developer treat the conversation like a literal slot machine.

> I think it will be second nature to ask "how did you arrive at the code".

What about “Do you understand the code well enough to argue about it, its past, and possible evolution paths”?

I think that would be implied by "how did you arrive at the code". I think the conversation will revove around how did you "guide" things.

Not really, I don't think I've ever care about the how. I want to mostly know the trigger of a change (a bug, possible feature, or just tidying) and what are the impacts if that changes is included in the codebase. That is often just a paragraph or two.

The workflow is mostly worthless, unless it can generalize and evolve into a process. And that is more worthy of a blog post or a presentation.

Hi! I work at Entire. We actually have another feature that we announced called Trails which indicates Confidence, Risk, Drift of code changes to give the maintainer more confidence that the code is high quality.

Each of those signals -- confidence, risk, drift are determined by a workflow file that the maintainer can create.

And trails continuously evaluate every time a change is made.

So that's exactly what we're doing..a gate that checks and weighs and measure everything before it gets committed.

The point of us capturing the agent sessions is so we can do more things with it..like adding "gates" that verify quality!

Who would trust the classifiers, though? I would not.

A team of professionals will trust a gateway they built themselves -- by an AI, most likely, as that is boring work -- that works for their organisation and whatever weird quirks and house styles they have. In a year or two when things are a bit more stabilised that'll be dozens of subagents each testing a little thing each in isolation plus a bevvy of software that looks for antipatterns in addition to running tests and linters and what have you. It'll be tested against the ground truth specification and not the boring crap in the middle.

At no point will anybody's session matter. Results count; nothing more.

classifiers are determined by the team that's working on the repo. Not by us! They're configuration files..like how in CI/CD you write a workflow file that needs to have passing tests. Same thing.

Reply on news.ycombinator.com