Live data from Hacker News

Astra for Coding: Why Are We Doing This Again?

lucumr.pocoo.org

101–110 of 334 posts

Re: Astra for Coding: Why Are We Doing This Again?

#101

I’ve observed exactly these patterns with Opus and Fable as well - for example, forgetting that they can edit files and instead use python scripts as a patching tool…

The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).

Re: Astra for Coding: Why Are We Doing This Again?

#102
post #81

Earlier quoted context omitted.

Sounds like you completely lack all reading comprehension ability LLMs sometimes like to execute one-off Python scripts to make edits to files rather than just calling the edit tool directly. Both are tool calls so saying that you should have it write code instead of doing tool calls makes no sense because writing code is a tool call for it...

[flagged]

[deleted]

Re: Astra for Coding: Why Are We Doing This Again?

#103

In SWE I've found gpt-6-astra (high) inconsistent and oddly focused on overtly taking responsibility for mistakes it made rather than prioritizing concrete steps to rectify problems. Such steps once elicited are often either incomplete or beyond the scope.

Yes I agree. I got it to vibe up a simple react router app. When it crashed it was obvious that it had totally swallowed all errors in the name of a tidy error page. Getting it to re-add logs and debuggable errors was an exercise in patience as astra just got more and more tweaked while trying to solve the problem.

From an alignment perspective I’ve got no idea who it’s aligned to but it isn’t me, the meat proxy, who just wants to know why it crashed.

Re: Astra for Coding: Why Are We Doing This Again?

#104
post #23
post #21

Earlier quoted context omitted.

Why would you use a constrained edit tool when you are also allowed to use the complete power of python?

Why even offer the edit tool in that case? Also, what kind of editing could they possible do what wouldn't be possible with POSIX ed?

You can chain a lot more commands together with this technique than with a single Edit tool call.

Re: Astra for Coding: Why Are We Doing This Again?

#105
post #68

This matches my experience with Astra so far too. > I think I’m suspecting something is going “wrong” in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for “shitty code.” My suspicion is that both OpenAI and Anthropic moved their RL agendas from "being rated as useful according to human feedback" to "succeeds at long hor…

I wouldn't be surprised if they are optimising for producing more code, because in the long term, more existing code means they can sell you more tokens to maintain it.

Re: Astra for Coding: Why Are We Doing This Again?

#106
post #17

Earlier quoted context omitted.

Most would applaud that as Sol has quite a reputation for over engineering. Not every software needs to go to the moon.

So your experience is that Astra doesn't over engineer? For more than twice the price of Sol I think most people will take the over engineering.

I found it to be less annoying in that regard then sol. Might just be that it better listens to what I instruct though.

But yeah, it's really expensive, at least in relative terms.

Re: Astra for Coding: Why Are We Doing This Again?

#107
post #15

These machines are doing some crazy things to get to the result. That said, I can't help but feel like this is the compilers argument all over again. Are the methods used to get to the result good? No. Is the code that it generates good? No. Does it achieve the goal. Yes. Is it likely to get better with time. Also yes. In my use cases, jobs that would have taken weeks to months are being done in minutes to hours. Inv…

What is the "compilers argument"?

Hand writing assembly produces more efficient and concise code, at the cost of developer time and required expertise. It was true for a long time, now not so much.

Re: Astra for Coding: Why Are We Doing This Again?

#108

> I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming…

But doesn't this reduce the required amount of farmland?

There is no “required” amount. More gets produced using the same area, using more people, but keeping these people in poverty because productivity per capita doesn’t increase. Instead the gains from the increased volume of production get captured by an elite. See https://link.springer.com/article/10.1186/s41257-019-0021-y.

Re: Astra for Coding: Why Are We Doing This Again?

#109
post #81

Earlier quoted context omitted.

Sounds like you completely lack all reading comprehension ability LLMs sometimes like to execute one-off Python scripts to make edits to files rather than just calling the edit tool directly. Both are tool calls so saying that you should have it write code instead of doing tool calls makes no sense because writing code is a tool call for it...

[flagged]

Are you saying scripts from agents are deterministic? :)

Re: Astra for Coding: Why Are We Doing This Again?

#110
I'd like to submit my counterpoint. I work on an established codebase building new features and fixing bugs. It has access to our story board, git and a couple of other mcps. As long as the story is well written with clear requirements and expectations it always produces quality code that I validate as a human with a variety of tests automated and manual. I peer review the code. My colleagues then peer review that too.

I have noticed two things - new features take at a minimum at least half the time it took me previously and bugs are much less frequent. Even faster when bug fixing.

My takeaway is that you need solid requirements, clear context and thoughtful human oversight primarily during planning but also during verification

Post reply on HN