Live data from Hacker News

Astra for Coding: Why Are We Doing This Again?

lucumr.pocoo.org

151–160 of 334 posts

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

#151
I have been quite disappointed with Astra. I switched over a week ago and I didn't notice a massive difference compared to Sol at first, but I figured I'd use it anyway because it surely can't be worse. Then I saw the bill, it's burning my subscription 10x faster than Sol for essentially no benefit. Not only is it more expensive per token, it also seems less token efficient. And not obviously any better. I'm back to a combination of Sol + Claude.

I also use Astra at work where I don't need to worry about token cost on highest effort and same story there, I don't see any difference in everyday work other than it being more expensive. Of course my experience is highly subjective, but with how meaningless/overfit the benchmarks are, subjective experiences are imo what matters.

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

#152
post #146
post #115

Earlier quoted context omitted.

Why don't you try to dispove me. Yes, they are _more_ deterministic than tool calls and consume less tokens.

There is nothing to disprove as you don't understand what does a word mean. Deterministic is not a spectrum, they can either be deterministic or not. In both cases, they are not.

Oh, I'm so sorry I touched your paper feelings.

How dared I to imply that some LLM output is more deterministic than the other, your LLM majesty. Shame on me and my entire family! For generations to come!

So sorry I implied that the code that doesn't work and has to be fixed later is deterministic in its execution and can be reused later instead of being re-generated from scratch!

Will I ever wash it off my name, your grace?

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

#153
post #11

"But for how much more Fable costs, for how much more Astra costs, I do not feel like the results are there." we are in the middle of the beginning. Its just a weird take to talk about the newest model like this while we are still in a R&D phase. And these points don't matter if you let it search and analyse a bug, for example, or if you have good harness and a good architecture and let it do small PRs or if you do s…

Nobody seriously thinks that AI is still at a R&D phase. It's already heavily entrenched both in companies and the financial world. If it's getting worse for coding then thats a major problem

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

#154

When the code is shitty it becomes harder and harder for the models to make changes and this grinds progress down to a halt - this has been my experience with “factories” trying them and doing refining steps every few months. I sincerely don’t understand what the people who say they no longer read any code are doing, because it must be somewhat trivial to not run headlong into these issues that stack up time after ti…

Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process. I'm not convinced this style of "agentic engineering" saves much time. I guess if I was oblivious to what good code looks like, and didn't care about maintainability It wouldn't bother me so much, but it legitimately has e…

I'm genuinely not convinced it actually saves time once a full accounting has been made. You get the initial result faster, but then you inflict a super slow and torturous review process on yourself or a teammate. Even if the review manages to bring it up to parity, over time you will keep slowing down as more and more code was never written by the humans directing the agents, so their understanding decays.

I at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.

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

#155
post #55

Early lesson I learned from AI engineering was - there is no substitute to giving a groomed epic to an agent. Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual. You need to say exactly what is in scope and what's not, even down to a buttons, events and layouts. You can groom the epic with the help of AI, but final review must be done by someone who can…

If you define what you want in typescript by updating existing typescript wordage, you get what you want exactly as specified, with minimal token cost and no ip theft.

I mean then it might be difficult to get stakeholder's alignment on specs written in typescript though.

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

#157

When the code is shitty it becomes harder and harder for the models to make changes and this grinds progress down to a halt - this has been my experience with “factories” trying them and doing refining steps every few months. I sincerely don’t understand what the people who say they no longer read any code are doing, because it must be somewhat trivial to not run headlong into these issues that stack up time after ti…

> I sincerely don’t understand what the people who say they no longer read any code are doing Well that one's easy to answer, they're either A) lying, or B) working on the simplest possible software where this kind of stuff doesn't explode. Or the alternative 3rd option of what you mentioned, the initial pre-MVP phase goes decently but then it all collapses inevitably as the slop accumulates and the codebases become…

Also there is also category C: they are not developers and they don't care about the code at all, but also not really much about the product. They just want to tick the boxes.

They blindly accept that LLMs "take time" after the slop grows because they're running several agents at the same time, so they can still claim to be productive.

Does it move the needle, business wise? Not really. But a lot of businesses are "optimising" for maximum token usage and for how many tasks one person can do, not for business value. Is it really surprising?

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

#158
post #82
post #46

Earlier quoted context omitted.

Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers. Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers. Comparing LLM…

There is also a predictable relation between the input and output of a compiler w.r.t. the semantics of a programming language. Natural languages are ambiguous leaving room for the implementation to diverge that may not be obvious at first glance.

There are also plenty of things a compiler might not expose that end up being ambiguous. For example, C++ doesn't officially have a restrict keyword, so how can you express the fact that two memory regions never operlap and can be optimized? Unfortunately the reality is that if we had a language capable of truly expressing the programmer's intent we'd end up with a monster

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

#159

When the code is shitty it becomes harder and harder for the models to make changes and this grinds progress down to a halt - this has been my experience with “factories” trying them and doing refining steps every few months. I sincerely don’t understand what the people who say they no longer read any code are doing, because it must be somewhat trivial to not run headlong into these issues that stack up time after ti…

Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process. I'm not convinced this style of "agentic engineering" saves much time. I guess if I was oblivious to what good code looks like, and didn't care about maintainability It wouldn't bother me so much, but it legitimately has e…

Quality code is easy to make changes to. What makes terrible code terrible is that changes become harder and harder to make over time. LLMs haven’t solved this, but the marketing acts as if it has, and many engineering orgs seem to have instantly forgotten the things we’ve learned from the last few decades of building software.

Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.

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

#160
post #46

Earlier quoted context omitted.

Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers. Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers. Comparing LLM…

What you say is true, the comparison indeed doesn't hold. But is it relevant? does it matter from a product perspective if LLMs are non-deterministic. You don't need to one shot the correct result, english is ambiguous and LLMs non-deterministic, but you can iterate. If it's possible to iterate fast and cheap enough, even ambiguous language can produce the results you want, given enough iterations. There are a lot of…

I think it matters, because nowadays we don't look at assembly any more. I mean, I don't recall the last time I was tracking down a compiler bug but it's definitely been more than 15 years ago.

We do have to look at the LLMs' output, though, and, as you already pointed out, iterate to get the correct results. What this means is that the output must still be readable, must be analyzed by someone and I don't see it going away any time soon.

The problem is that the analysis is not cheap. Sometimes, with boilerplate, it is easy, but many times it is not and that's where we get only slight gains by using LLMs.

Post reply on HN