Live data from Hacker News

Astra for Coding: Why Are We Doing This Again?

lucumr.pocoo.org

161–170 of 334 posts

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

#161
post #62

Earlier quoted context omitted.

it reminds me of a thread I read on PTT, Taiwan's Reddit. AI finally achieved what humans could not. Managers must give exact context for what they want, must pay exact wages (tokens), and can't delay salary payments (which seems to be a problem in China).

Yeah it's a funny thing - a lot of the things you need to feed the model are things that actually would have helped humans...

Starting with agentic task-time "grounding" being just good documentation, and "skills" being just playbooks and user guides.

Hell, skills are increasingly paired with dedicated CLI tools, that remove jank from actual utilities and adapts them to be token efficient.

So now, any CLI `tool` people want AI to use eventually grows `tool/SKILL.md` and then a `tool-for-llms` wrapper that exposes task-specific, logical, higher level interface, then the skill is rewritten in terms of "for LLMs" wrapper. The procedural knowledge moves from Markdown into the wrapper, making the skill more token efficient, and both skill and the tools are optimized for common tasks and... at this point, we are doing actual UX engineering.

Now the truly interesting part is the difference between what's good UX/DX for LLMs vs humans. Turns out, the conceptual/abstract/cognitive part is pretty much the same: which is why skills still look indistinguishable from well-written documentation for humans, and why the commands exposed by "tool but for LLMs" make sense to us. Same way of grouping ideas into higher level concepts.

No, the main difference is just that LLMs are perfectly content with tightly packed unprettified JSON, or other forms of Perl line noise. The tool output doesn't need to look nice, or to have any spatial structure - they're reading it token by token anyway, and the tokens come from a tokenizer that's reading it byte by byte.

That points at an interesting asymmetry for humans. LLMs are doing I/O the same way in both directions: sequences in, sequences out. Humans only do sequential output - inputs, particularly visual, are processed holistically.

For us, what's easy to read is hard to write, and what's easy to write is hard to read. LLMs don't have this friction.

(I don't know what the implications of this are, I just find this interesting.)

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

#162
post #30

I love this dance we are doing where when people write the "AI models are garbage machines that produce garbage and are no where close to the fantasy being pedalled by the Crypto bros who pivoted to AI" it always has to be caveated with "AI models are useful and I am highly productive with them" It feels like people should just be able to say "This article comes with the standard disclaimer" and just dive into the me…

But we can’t do away with the quasi-religious lip service to the canons of the AI creed now can we? /s

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

#163

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…

Part of the explanation (for me) is that the slow down comes later, and that part of the cost is externalized to team members. If you go all-in agentic on a project that has at least reasonable code quality, you can certainly gain a temporary boost by stopping to read the code for a while. At least long enough to get yourself and the rest of the team hooked on the idea.

Kinda reminds me of the "beginner's luck" problem for gamblers.

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

#164

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…

> saves much time

Reviewing and reading everything makes this feeling, yeah.

However where I can say 100% it saves time is discovery by answering these questions:

  - At what state does bug X manifests?
  - Explain how integration/feature works.
  - I want to integrate with system X: Audit what items/features are used and what model changes are needed on my side

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

#166

I’ve asked Astra to build me an app for a prototype I created quickly using Sonnet. It’s been 2 days and it made no real progress on the actual app. It created docs, scripts, workflows, and it’s doing a bunch of reviewing on every PR. I told it that I just need an MVP. I’m pretty sure an average senior engineer would have finished that task much quicker, and guaranteed with more readable, higher-quality code. Meanwhi…

For me it also produces totally overengineered tests that are tightly coupled to the implementation. For example testing existence of css classes (in a template based go prooject ...) instead of behaviour.

Can you recommend any model that doesn't do this?

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

#168
The hype machine is this technology's worst enemy. When I zoom out and look at things objectively, it's kind of crazy what we have at our fingertips, we can talk to our computers in plain and even vague human languages and have the computers actually accomplish what we ask of it! It's literally sci-fi magic come to life, and the nerd in me finds it the coolest thing ever.

But then the industry and the companies involved in it have all ruined it with this INSANE hype machine that has been so hyperbolic and psychotic and full of lies since day 0. Instead of embracing it all in a reasonable manner as a useful tool that can help boost people's productivity in certain workflows, it now HAS to be the most transformative technology of all time lest the trillions of dollars burned up come crashing down on the entire global economy hard. It HAS to be AGI, it HAS to replace every single knowledge worker, it HAS to be the most dangerous technology ever known to man.

It's like we've completely lost the ability for subtlety, and everything HAS to be the biggest and best thing ever that will revolutionize humanity immediately. Not only have we lost subtlety, we're actively rewarding this idiotic short-sighted behavior and it's all just so depressing

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

#169
I have found these models to be useful either at super specific tasks (e.g., "take this function or algorith?m and find any black magic to make ot faster + validate and verify the hell oit of it"), or give it an entire thing to oneshot without oversight. The moment you have a hybrid workflow where you actually have to work and check and understand AI code, things get insane

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

#170
As another commenter pointed out, I feel that the biggest change that occurred in the last 6 or so months is that these tools are removing the human "hurdle" in order to complete a task at all costs. The best way to complete the task is to no longer ask for input, clarify unclear things or use existing solutions but code the whole thing yourself from start to finish.

I have had the misfortune of working with such people who are now encapsulated in Opus 5/Fable/Astra which means that you WILL get a solution, but it won't generally be maintainable or useful. Multiple times have I found myself stopping Fable or Opus or even Sol from building their own JSON validator in Python or god knows what else, because at the end of the day, the reward is to complete the task.

It's also one of the reasons why I'm finding older models more useful for the type of work I actually do and why I've been favoring something like Deepseek Flash. Just started using Flash 4.1, so not sure if it exhibits the same maniacal approach to tasks as the Western counterparts. (I only briefly tried GLM 5.2/5.3 and for nothing major, so I couldn't comment on those).

For context, 80% of my professional work relies on adding functionality to an existing code-base that is very difficult to work with, has a ton of business logic scattered across and was built in a go-go-go fashion many years ago. Since then people kept pilling "features" on top with no testing strategy in mind apart from the business manually testing it. Letting something like an LLM loose on the code-base would introduce soooo much risk that it's just untenable so the only way to work is to really isolate changes and then try to build out small reusable components. Even so I find Opus go off on a tangent "Hey, let's not bring in Markdig, I'll build my own Markdown rendering engine, give me 7 hours...".

I have written on the subject of LLMs previously on my personal page, I find them completely unnecessary and a trove of theft and value extraction through theft, but I understand that they can provide benefits when used judiciously. However, despite all the hype in the last few months, these latest models feel and behave off.

If I hold the answers to a test, you might score more in a test if you break my arms to get the answers out of me, but that doesn't make you smarter.

Post reply on HN