Readit NewsDifferent strokes I guess.
A wire sitting on a table does not suck. 2 people can gather around that table and still, the wire does not suck. As soon as 1 person picks up the wire and starts doing something with it....now an interaction with a wire sucks.
But that's not the wire's fault.
This can be overcome by continuously asking it to justify everything, but even then...
However, constant skepticism is an interesting habit to develop.
I agree, continually asking it to justify may seem tiresome, especially if there's a deadline. Though with less pressure, "slow is smooth...".
Just this evening, a model gave an example of 2 different things with a supposed syntax difference, with no discernible syntax difference to my eyes.
While prompting for a 'sanity check', the model relented: "oops, my bad; i copied the same line twice". smh
If the problem is that we don't trust people who use AI without understanding its output, and we base the gate-keeping on tests that are written on AI, then how can we trust that output?
If your premise is that people would shift to using AI to write tests they don't understand, then that's not necessarily a failing of the contributor.
The contributor might not understand the output, but the maintainer would be able to critique a spec file and determine pretty quickly if implementation would be worthwhile.
This would necessitate a need for small tickets, thereby creating small spec files, and easier review by maintainers.
Also, any PR that included a non spec file could be dismissed patently.
It is possible for users of AI to learn from reading specs.
But if agents are doing the entire thing (reading the ticket, generating the PR, submitting the PR)...then the point of people not understanding is moot.
I’d play it if payphones from my state were included! I don’t know if they are licensed/registered here though.
Google auth still not hooked up, but otherwise good enough for now. And it's open source.
Why not restrict the agents to writing tests only?
If the tickets are written concisely, any feature request or fix could be reduced to necessary spec files.
This way, any maintainer would be tasked with reviewing the spec files and writing the implementation.
CI is pretty good at gatekeeping based on test suites passing...
Does it write maintainable code? Does it write extensible code? Does it write secure code? Does it write performant code?
My experience has been it failing most of these. The code might "work", but it's not good for anything more than trivial, well defined functions (that probably appeared in it's training data written by humans). LLMs have a fundamental lack of understanding of what they're doing, and it's obvious when you look at the finer points of the outcomes.
That said, I'm sure you could write detailed enough specs and provide enough examples to resolve these issues, but that's the point of my original comment - if you're just writing specs instead of code you're not gaining anything.
yes, if I steer it properly.
It's very good at spotting design patterns, and implementing them. It doesn't always know where or how to implement them, but that's my job.
The specs and syntactic sugar are just nice quality of life benefits.
The original article is, to me, seemingly not that novel. Not because it's a trite example, but because I've begun to experience massive gains from following the same basic premise as the article. And I can't believe there's others who aren't using like this.
I iterate the plan until it's seemingly deterministic, then I strip the plan of implementation, and re-write it following a TDD approach. Then I read all specs, and generate all the code to red->green the tests.
If this commenter is too good for that, then it's that attitude that'll keep him stuck. I already feel like my projects backlog is achievable, this year.
Now what's meant to happen next?
In practice I mean.
It's one thing to add skills and system prompts to a project; it's another to accurately frame and orchestrate the various parts of a context window to maximize the inputs in an efficient way to optimize the outputs of these agents/models we've all begun using.
Practically: explore and influence definitions of context to refine your ability to contribute to the documents that steer the agents.
Or better yet, focus on a part of the context window and figure out how to expose resources responsibly.
Personally, I think local models are the future...but that's just a hunch
>But that's not the wire's fault.
So... "it's not the fall that kills you, it's the sudden deceleration"?
My assertion is that an inanimate object becomes a problem when a human interacts with it.
Your attempted logical argument is that a law of nature is the same as an inanimate object.
I am not contesting that an inanimate object is the same as gravity.
I'm saying that humans make bad decisions with simple things and whine about inanimate objects and that's a very real first world problem.