HackerTrans
TopNewTrendsCommentsPastAskShowJobs

brendanmc6

478 karmajoined 8 वर्ष पहले
Elixir / Phoenix convert

Submissions

Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

acai.sh
287 points·by brendanmc6·2 माह पहले·295 comments

Specsmaxxing

acai.sh
3 points·by brendanmc6·3 माह पहले·0 comments

comments

brendanmc6
·कल·discuss
Progress is a fiction? What an enraging and awful take. You are living in a world that is so extraordinarily safe, comfortable, populous, peaceful, free and entertaining your ancestors literally would not believe you if you told them. Most of your ancestors worked ten times as hard to access a tiny fraction of the material wealth and health and knowledge most people have today. Touch grass.
brendanmc6
·पिछला माह·discuss
I am also quite happy with Elixir output, and it’s much more pleasant to review. Unit test runs are fast, and testing LiveView is overall more pleasant and effective compared to similar Typescript / React projects I’ve maintained in the past.

I never considered “language stability” until your comment, but I think you are right. I’ve had far fewer dependency upgrade pains and a general feeling that bit-rot is slower overall.

Older apps that depends on Node + trendy npm packages + popular frameworks can be a real nightmare to bring up-to-date.
brendanmc6
·2 माह पहले·discuss
I’ll be more sensitive to that, thanks for the feedback.
brendanmc6
·2 माह पहले·discuss
Totally agree. This is 100% where I want to be focusing my energy next! A lot to learn and explore still, just need to find the time.
brendanmc6
·2 माह पहले·discuss
Fair critique, voiced elsewhere in this thread as well, I am regretting my use of the term.
brendanmc6
·2 माह पहले·discuss
[dead]
brendanmc6
·2 माह पहले·discuss
If you do end up taking a closer look (very much appreciated), take a peek at this security checklist I went over before publishing. I'm also scarred by all the supply chain attacks lately, do let me know if anything is missing.

https://github.com/acai-sh/cli/blob/main/docs/security.md
brendanmc6
·2 माह पहले·discuss
I think we are actually saying the same thing! We could think of situations where the cache would be verboten (sensitive info), or where it would be mandatory, like in your example, or optional like in my example.

My aim was to voice disagreement with the "code is spec" crowd, whom I think are using a different (and in my opinion tautological / useless / counterproductive) definition of spec. Probably because they are mad that I use trigger words like Vibe and Maxxing, and they assume I can't even read the code I'm shipping. I digress.

In your "time complexity is a downstream requirement" example, which is a great one, I think you would prefer to have well-maintained written documentation of that criterion that lives outside of the procedural code itself, would you not? How much attention that doc gets is a matter of process and preference, but I'm advocating it should get more (spec-first).
brendanmc6
·2 माह पहले·discuss
Ah, I should have said explicitly or provided an example of in the post;

The tooling expects that you refer to each requirement by full ID e.g.

  # admin.AUTH.1
brendanmc6
·2 माह पहले·discuss
Here is how I got from Markdown to YAML in a few easy steps:

1. Start with unmaintainable prompt.

  Add auth to the admin route. It must only be accessible to team members. It must not be accessible to team members with the `quarantine` role. Unauthorized users should be redirected to the /login page, with query param `?error=unauthorized`. Requires fresh session, no older than 10 minutes.
2. Put it in a structured .md spec of some kind

  # Feat: Admin Route

  ## Auth requirements

  * [ ] Accessible to team members.
  * [ ] Not be accessible to members with `quarantine` role.
  * [ ] Redirects unauthorized users to /login
    * [ ] Redirect path includes `?error=unauthorized`
  * [ ] Requires fresh session, no older than 10 minutes.
But how do you cross reference the requirements? Give them stable IDs?

  # Feat: Admin Route

  ## Requirements

  AUTH.1: Accessible to team members.
  AUTH.2: Not be accessible to members with `quarantine` role.
  AUTH.3: Redirects unauthorized users to /login.
    AUTH.3.1: Redirect path includes `?error=unauthorized`.
  AUTH.4: Requires fresh session, no older than 10 minutes.
Might as well clean it up and make it machine readable at that point?

  feature:
    name: admin-route

  requirements:
    AUTH:
      1: Accessible to team members.
      2: Not be accessible to members with `quarantine` role.
      3: Redirects unauthorized users to /login.
      3-1: Redirect path includes `?error=unauthorized`.
      4: Requires fresh session, no older than 10 minutes.
```
brendanmc6
·2 माह पहले·discuss
I think you are confusing the spec as "this is how it must be built", as opposed to, "this is what the software must do and must not do to be acceptable".

To me saying "the code is the spec" is like saying "the business wants it this way because that's how the code is written". Which is obviously backwards.

Does the business mandate we use a cache for this hot path? No, but the business set performance targets, and the cache was a sensible way to satisfy them. See the difference?

I believe that the 'musts' and 'must nots' deserve special attention, and need to be recorded well before I decide on the 'how'. Every team does this differently. I find that writing itemized, functional acceptance criteria is practical way to marry the two domains. I also think the process matters a lot more now, because the temptation to let an agent ship it is increasing and the tedium of maintaining these specs is decreasing.
brendanmc6
·2 माह पहले·discuss
I guess I misappropriated the term then, woops. AI OCD? AI obsession? Whatever you call the behavior that I saw myself and others falling in to. Getting obnoxiously fixated on the tooling and the models to a counterproductive degree.
brendanmc6
·2 माह पहले·discuss
Ooh thought I did that, thanks.
brendanmc6
·2 माह पहले·discuss
Totally agree it's not exciting, even though I am personally excited by it, and I also agree it's not something most people want to try, even though some people do want to try it-- and I found a few of them right here on HN.

Disagree on the bit about it "never going to work" though.

Failure-prone stochastic ML systems produce testable, auditable code... just like failure-prone human brains can produce testable, auditable code. And in fact, in both cases, changes to our process can reduce the amount of failures that slip past testing and audit. Or can reap other rewards. Finding the a better process is what I'm interested in right now.
brendanmc6
·2 माह पहले·discuss
It's ok friend, all I did is put acceptance criteria in a list so I can parse it and quickly track cross-references. The rest is just Elixir/Phoenix and some creative writing.
brendanmc6
·2 माह पहले·discuss
Fair, I could have made that point clearer. It's a couple things. First is that I finally stopped experimenting with TUIs, harnesses, models, subagents, roles, skills, mcp, md libraries etc. and have mostly settled on this approach, and got back to building other things with it. I'm sure that won't last forever though.

Second is that I'm doing a lot less "seat of my pants prompting" and doing more engineering and ideating, which was a big goal of mine. So I'm feeling less psychotic there too.

And sort of tangentially to that, I think a significant subset of devs actually are willing to just prompt their way to nirvana, day in and day out. I'm not. I think the spec will carry a lot of weight for a long time. Maybe they will get further than I give them credit for? Maybe the whole digital world becomes a single chat box?
brendanmc6
·2 माह पहले·discuss
Should I apologize for being excited about something I built and use daily and for wanting people to try it, discuss it, critique it? Not sure by the tone of your message.
brendanmc6
·2 माह पहले·discuss
Oh cool, thanks for sharing. LLMs tend to adopt these patterns on their own, so I'm sure my ideas are far from unique.
brendanmc6
·2 माह पहले·discuss
Indeed I have a lot of catch up to do, will spend some time with the popular tools before I go too much further down this road.
brendanmc6
·2 माह पहले·discuss
Author here, if you don't want to read all that, I'll post one excerpt that I think sums it up nicely:

> My point is, the spec must live somewhere, even if you don’t write it down. The spec is what you want the software to be. It often exists only in your head or in conversations. You and your team and your business will always care what the spec says, and that’s never going to change. So you’re better off writing it down now! And I think that a plain old list of acceptance criteria is a good place to start. (That’s really all that `feature.yaml` is.)