HackerTrans
トップ新着トレンドコメント過去質問紹介求人

brendanmc6

477 カルマ登録 8 年前
Elixir / Phoenix convert

投稿

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

acai.sh
287 ポイント·投稿者 brendanmc6·2 か月前·295 コメント

Specsmaxxing

acai.sh
3 ポイント·投稿者 brendanmc6·3 か月前·0 コメント

コメント

brendanmc6
·15 時間前·議論
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
·先月·議論
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 か月前·議論
I’ll be more sensitive to that, thanks for the feedback.
brendanmc6
·2 か月前·議論
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 か月前·議論
Fair critique, voiced elsewhere in this thread as well, I am regretting my use of the term.
brendanmc6
·2 か月前·議論
[dead]
brendanmc6
·2 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
Ooh thought I did that, thanks.
brendanmc6
·2 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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 か月前·議論
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.)