[dead]
Astra for Coding: Why Are We Doing This Again?
331–334 of 334 posts
Re: Astra for Coding: Why Are We Doing This Again?
#332[dead]
Re: Astra for Coding: Why Are We Doing This Again?
#333Earlier quoted context omitted.
> I sincerely don’t understand what the people who say they no longer read any code are doing Welcome to the present. Like many of us do not read the machine code generated by a C++ compiler, the code generated by an agent is similarly irrelevant and disposable, by now.
The machine code generated by a compiler is deterministic and reproducible (assuming using same chain/tool versions), which is why reading the human readable pre-compiled source is sufficient. Reading a prompt but not reading the non-deterministic/non-reproducible LLM output is not comparable. How do you know it does what you want it to do without reading it? Tests? How do you know what they test? Yes, clicking a but…
Yeah, tests. You need tests for everything and the tests + API needs to be carefully reviewed. Technically, the implementation need not be read at all. Just APIs, boundaries, and tests. You need unit tests, mutation tests (tests for your tests), integration tests, and end-to-end tests. You also need to design the system to be broken up into small submodules, which is how software should be written anyway. You push all side-effects right to the edge, and then test the core extensively.
Nobody needs to understand the whole. They only need to understand each submodule, which is easy. And then, how they interact, in which case you only care about the API and contract garauntees, not the implementation.
Realistically, this is how pre-AI software engineering worked, too. Or how it should generally work. Nobody can read or understand a 10 million line codebase. So to ensure you don’t break shit, you need the submodules, orchestration, and tests.
Re: Astra for Coding: Why Are We Doing This Again?
#334Earlier quoted context omitted.
I’ll try to explain how to do it correctly. I’m not selling anything. Seeing this as the top comment makes me a bit sad. 1. Learn about ports and adapters as an architecture pattern. Domain driven design and locality of reasoning are your new best friends. 2. Realize that AI can generate unlimited fake data almost immediately. So anything you can isolate can get a fake adapter and a real one. You can build and test a…
I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small t…
Not to be tautological, but isn’t the product the product?
Which code? The high level code? The transpiled intermediate code? The assembly it runs on eventually? The microcode optimizations on the processor?
I’ve written assembly professionally. That code matters occasionally. But mostly I don’t worry about it. I don’t worry much about the transpiled JavaScript tsc output either. Or the intermediate code generated for LLVM. Or the bytecode most managed languages make for their interpreters.
Like I said, you still have to do the hard parts, but most of software development is boilerplate or yet another implementation around the hard parts. AI is a tool you have. Using it effectively does not mean it is your only tool.
Also, profit is not the ultimate metric. Value provided is the metric. Optimizing for money, to paraphrase a great book, is like trying to get better at tennis by studying the score board.