11 ms·

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

• brendanmc6 5mo ago
  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.)
  • gnat 5mo ago
    Nice! Your spec-maxxing is very resonant. I've been doing working with explicit requirements: elicit them from conversation with me or introspecting another piece of software; one-shot from them; and keep them up-to-date as I do the "old man shouts at Claude" iterations after whatever one-shotting came up with. Unlike you, I wish for the LLM to do as much of the work as possible -- but "as possible" is doing a lot of work in that sentence. I'm still trying to get clear on exactly where I am needed and where Opus and iterations will get there eventually. It has really challenged me to get clearer on what a requirement is vs a constraint (e.g., "you don't get to reinvent the database schema, we're building part of a larger system"). And I still battle with when and how to specify UI behaviours: so much UI is implicit, and it seems quite daunting to have to specify so much to get it working. I have new respect for whoever wrote the undoubtedly bajillion tests for Flutter and other UI toolkits.
    • gnat 5mo ago
      Forgot to add: I get several benefits from doing this. 1. Specifications that live outside the code. We have a lot of code for which "what should this do?" is a subjective answer, because "what was this written to do?" is either oral legend or lost in time. As future Claude sessions add new features, this is how Claude can remember what was intentional in the existing code and what were accidents of implementation. And they're useful for documenters, support, etc. 2. Specifications that stay up to date as code is written. No spec survives first contact with the enemy (implementation in the real world). "Huh, there are TWO statuses for Missing orders, but we wrote this assuming just one. How do we display them? Which are we setting or is it configurable?" etc. Implementer finds things the specifier got wrong about reality, things the specifier missed that need to be specified/decided, and testing finds what they both missed. I have a colleague working on saving architecture decisions, and his description of it feels like a higher-abstraction version of my saving and maintaining requirements.
      • energy123 5mo ago
        I do (1) the same but (2) differently. In my workflow, (2) are AI generated specs using human written (1) as the input. It's an intermediate stage between (1) and the codebase, allowing for a gradual token expansion from 30k to 250k to the final code which is 2-3M. The benefit I've found with this approach is it gives the AI a way to iterate on the details of whole system in one context window, whereas fitting the whole codebase into one prompt is impossible. The code is then nothing more than a style transfer from (2).
        • kennyloginz 5mo ago
          Jfc
        • hansmayer 5mo ago
          Let's cut through the noise - what did you build with this very elaborate process and how much ARR is it generating ?
          • rrgok 5mo ago
            Asking the real questions. I would also really like know how much value AIs are bringing in terms of ARR or MRR.
      • try-working 5mo ago
        Specifications doesn't tell you what to do, they say what the end state should be. In between that you need a codebase analysis step and an implementation plan. My recursive-mode workflow handles all of that and more and gives you full traceability: https://recursive-mode.dev/introduction https://recursive-mode.dev/introduction
  • slopinthebag 5mo ago
    I actually read it all since it did not contain any hints of being AI generated (although I wouldn't be surprised to learn you did use AI to write it), so thank you for that. It's kind of crazy how I now have the default expectation that posts posted here are AI slop with little thought or care put in. I am also stealing the idea of talking to LLMs as if it's an email. So funny, we need to be joymaxxing a bit more I think :)
  • nalpha 5mo ago
    What's the difference between this and Jira. Your specs already live somewhere, it's where you defined them. That's why it's nice to put the Jira ticket number in your code / commit, so you can refer back to the spec when something breaks
    • Diti 5mo ago
      What about when you migrate away from Jira, or when there’s a Cloudflare outage?
      • foobarbecue 5mo ago
        1) export 2) backup
    • cowanon77 5mo ago
      Jira is only a set of changes though. What happens on a long (10+ year) and complex (10+) developer project with many changes and revisions? Eventually you need an explicit specification that itself has a "current state", and a change log. Theoretically you could generate this from Jira, but in my experience it eventually became a mess on any larger project that didn't have explicit and maintained writen requirements.
      • foobarbecue 5mo ago
        Jira has current state and a change log. The proposal here is "use yaml instead of jira." Same damn thing, same damn mess.
    • mike_hearn 5mo ago
      A specification isn't a series of change requests! Using Jira as your source of truth is no different to just recording all your prompts. There's nothing you can easily review to spot contradictions or how things interact with one another. I've been doing "specmaxxing" for a few months now. Unlike the author I don't use Yaml, I use a mix of Markdown and Gherkin. If you haven't encountered Gherkin before, it's not new and you might know it under the name Cucumber or BDD. https://cucumber.io/docs/ https://cucumber.io/docs/ Gherkin is basically a structured form of English that can be fed into a unit testing framework to match against methods. The nice thing about writing acceptance criteria this way is that they become executable and analyzable. You write some Gherkin and then ask the model to make the tests execute and pass. Now in a good IDE (IntelliJ has good support) you can run the acceptance criteria to ensure they pass, navigate from any specific acceptance criteria to the code which tests it (and from there to the code that implements it), you can generate reports, integrate it into CI and so on. And when writing out acceptance tests that are quite similar, the IDE will help you with features like auto-complete. But if you need something that isn't implemented in the test-side code yet, no big deal. Just write it anyway and the model will write the mapping code. There's a variant of Gherkin specifically designed for writing UI tests for web apps that also looks quite interesting. And because it's an old ecosystem there's lots of tooling around it. Another thing I've found works well is asking the models to review every spec simultaneously and find contradictions. I've built myself a tool that does this and highlights the problems as errors in IntelliJ, like compiler errors. So I can click a button in the toolbar and then navigate between paragraphs that contradict each other. It's like a word processor but for writing specs. Once you're doing spec driven development, you don't need to write prompts anymore. Every prompt can just be "Update the code and tests to match the changes to the specs."
  • DonHopkins 5mo ago
    Great idea -- just one suggestion if you want it to catch on: perform some IncelCultureMinning on the nomenclature. You probably don't want people associating your work with abusing crystal meth and hitting yourself in the face with a hammer. For anyone missing the reference, SNL has a pretty good explainer: https://www.youtube.com/watch?v=4XMPLdiXB1k https://www.youtube.com/watch?v=4XMPLdiXB1k
  • beshrkayali 5mo ago
    I wrote something similar recently about how agent-generated code lacks the institutional memory that human-written code has. There's nobody to ask why a decision was made (1). “Specsmaxxing” is basically the right response to this. When you can't rely on authorial memory, you have to put the intent somewhere durable. Specs become the source of truth by default if we continue down the road of AI generated code. 1: https://ossature.dev/blog/ai-generated-code-has-no-author/ https://ossature.dev/blog/ai-generated-code-has-no-author/
    • nicbou 5mo ago
      I had a similar experience refactoring a large codebase• The only thing that made it possible was that each commit message had a JIRA ticket number tying it to a requirement or task. I could find the people behind the business logic and ask them about it.
    • try-working 5mo ago
      the recursive-mode workflow has full traceability, including why decisions were made, what the original requirement was, what the previous state was, etc. https://recursive-mode.dev/introduction https://recursive-mode.dev/introduction
      • beshrkayali 5mo ago
        [dead]
    • bizzletk 5mo ago
      I've been attaching to my commit messages a Git Trailer [1] of the Session UUID from the Claude Code conversation that created that commit. It allows Claude to look back into the session where a change was made and see the decisions made, tradeoffs discussed and other history not captured by code, tests. [1] https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers
      • chickensong 5mo ago
        A few questions: - Does Claude leverage the trailers automatically, or is usage initiated by you? - How often are you using the trailer lookups? - Any idea how this relates to token usage? If you're frequently busting cache on old sessions, it might be cheaper to read a local doc.
  • hansmayer 5mo ago
    > will always care what the spec says, and that’s never going to change Did I miss something or is everyone back in 1970s, working in waterfall processes now?
    • JohnHaugeland 5mo ago
      waterfall doesn’t mean writing down decisions
    • scandox 5mo ago
      All through the agile era I wrote detailed specs for projects and then followed an agile process. The most successful parts of every project were the ones that we were able to spec best even when they diverged significantly from the original spec. You don't plan to follow the plan. You plan in order to understand the whole problem space. Obviously no plan survives contact with reality.
      • fsloth 5mo ago
        Agree! Another point of view is that LLM:s perform to an extent on the same level as outsourcing does. This interface requires a bit more contract mass than doing everything within single team.
      • chrisweekly 5mo ago
        "Plans are worthless, but planning is essential."
        • kaffekaka 5mo ago
          Pointless nit, but replace "essential" with "invaluable" for a play with words.
          • chrisweekly 5mo ago
            I like wordplay too, but in this case it'd have risked muddling the lone point I was making. Doubling down on tangents, since you like wordplay I bet you'd enjoy https://tiledwords.com/ https://tiledwords.com/ which has been posted on HN a couple times.
  • colechristensen 5mo ago
    So what I'm building is a github clone with epics/issues/kanban + specs/requirements/standards + CI/testing/coverage with the idea that all of those things connect so issues+requirements+testing all interact via code+webUI+CLI the point being that we can specify how a product is to function and the steps to get there and it's less a matter of telling a person or an LLM to read and implement the spec and more software actually keeping track at all times.
  • Twey 5mo ago
    The traditional name for this spec is ‘source code’ — a canonical source of truth for the behaviour of a system that is as human-readable as we know how to make it, that will be processed by automated tools into a less-readable derived artefact for a computer to execute. Checking the compiled artefact into the codebase without checking in its source code has always been a risky move!
    • fragmede 5mo ago
      Technology evolves and traditions change. What persists is the role, not the filename and its extension. Weddings are still weddings even after things went from painted portraits to film cameras to camcorders to smartphones to livestreams. Same with birthdays. Cards became phone calls, Facebook wall posts, group chats, shared albums, or generated videos (Sora, RIP). The tradition of having a deck of punch cards evolved to having assembly, to Pascal, Fortran, C, basic. The important part is a human-auditable directive, not an opaque, generated artifact as the thing that matters. have evolved and adapted. Photography, film cameras, polaroids, camcorders, digital cameras, smartphones, social media, Zoom/virtual attendees. Same with birthdays. Handwritten cards, to phone calls to e-cards, Facebook wall posts, video calls, shared photo albums and Sora (RIP) videos.
      • Yokohiii 5mo ago
        > The important part is a human-auditable directive, not an opaque, generated artifact as the thing that matters. Your arguments create a false dichotomy. You look at it from consumer perspective, while coding and it's artifacts are usually done by suppliers. If you change camcorder to tv advertisement, the requirements shift. The human auditable directive and the outcome matter. Coca Cola probably has very high standards for their IP (the directive) and doesn't care about the outcome (AI slop ads). The result is disgruntled consumers. If you don't care about the "opaque" generated artifact, then you are Coca Cola.
        • Twey 5mo ago
          As far as I understand it I'm on your side in this argument — I think ‘code’ continues to matter so long as the LLM-to-execution pipeline remains a leaky abstraction — but I don't think the analogy is correct. The ads are the resultant behaviour of the software, e.g. the UX, not the code.
  • K0balt 5mo ago
    I independently converged on something similar. I use two to three specification docs for my c++ work: a firmware manual (describes features and interfaces)) , an implementation plan (order of implementation, mechanisms where specified - new features go in here) and a product manual ( user story, external effects) I start with a user story, build an implementation plan, write the code, write the firmware manual, check the 3 documents +code for consistency and coherence. Either change the code or the documentation to reflect a coherent unified truth. (Implementation plan gradually becomes as-built) I also have the code comprehensively commented so that it is difficult to misinterpret. “Correct, coherent, consistent, commented” We iterate feature by feature through this process, and occasionally circle back on the original product manual to identify drift. After the original documentation is drafted, I have the agent write up placeholder files and define all of the interfaces we expect to need (we will end up adding a lot later, but that’s ok) every file should reflect a clear separation of concerns, and can only be reached into through its defined interface, all else is private. I end up with more individual files than I would by hand, but by constraining scope at file granularity, and defining an inviolate interface per file, I avoid the LLM tendency to take shortcuts that create unmaintainable code. I also open each new context with an onboarding process that briefly describes the logos and the ethos of the project, why the agent should be deeply invested in the success of the project, as well as learnings.md which the agent writes as it comes across notable gotchas or strong preferences of mine. Needless to say, I use one million context , and it’s a token fire… but the results are solid and my productivity is 5-10x
  • rogermarley 5mo ago
    This ultimately converges on what source code is though. The most common form of what you'd call a "spec" is the acceptance criteria on a work ticket, which is an accretive spec i.e. a description of desired change -- "given what already exists, change it as follows". I.e. if you somehow layered and summarized and condensed all tickets that have been made since product started, you'd have your "spec". But it's the devs who were doing that condensing via understanding each desired spec addition vs reality of existing codebase. So the gap between what people are currently calling "specs" what the code was already doing is not big and will not stay big, but for the fact you're effectively adding another (quasi) compile step underneath - and in this case its a non-deterministic one.
  • algoth1 5mo ago
    So basically, talk with a rubber duck, but record the conversation
  • jacquesm 5mo ago
    You have rediscovered the job of Software Analyst, which until the early 90's was a thing. Then that all got upended and we ended up with a mix between product owners, project managers and developers / devops but I think that that ignores the fact that Analyst is a different set of skills.
    • moffers 5mo ago
      I came up as a software requirements analyst before the weird transition between business analyst to product owner to product manager to technical product manager. But living in requirements for 15+ years really gave me a leg up on these “let’s go back to requirements!” efforts.
      • jacquesm 5mo ago
        It always amazes me how bad the software world is at keeping lessons learned as learned, especially when compared to say engineering. It's as if every 20 years or so we throw away the books and reinvent it all from first principles, hopefully this time with fewer mistakes overall but usually we end up finding both new ones and re-do some old ones.
        • arvid-lind 5mo ago
          It's almost like "move fast and break things" isn't such a good mantra.
        • enraged_camel 5mo ago
          It's because software engineering, which deals with bits, evolves dramatically faster than other engineering disciplines, which deal with the physical world.
        • physicles 5mo ago
          It’s almost as if we need to write some unit tests. For our profession.
    • ebiester 5mo ago
  • skeedle 5mo ago
    Beyond writing the spec down, you can share the spec or use someone else's spec. That's why spex.build was created, to be a hub with versioned specs so people can just create their own implementations, in the language, style, and particulars that they want.
  • rufasterisco 5mo ago
    What not just record the conversation? If contains all that is needed. The initial at large scoping, the failed attempts at doing x and not y, how that specific line of code solves that specific edge case, etc. When it’s time to review, review both code and conversation. 200 “user written messages asking why and what”? Likely a good PR. 15 “yes, yeah, ok, whatever”? Well you might want to give that PR some love. It feels to me that when we commit, we throw away half, if not most, of the work done by not recording it.
  • behaviors 5mo ago
    The exact reason you should start with one first. I support maximum specification. Atomic if you will. Lucky for modern development, you don't have to write it, you just have to proof it. If you can read a spec, it can guide your development, might as well have a system to manage them.
  • Ancapistani 5mo ago
    I think my use case is a little different than yours - I’m wanting to use it as a framework for me and an agent to manage specs, then split implementation into a separate agent fleet and use the spec as the interface layer - but the tool itself looks great and should work well!
• up-n-atom 5mo ago
  the token usage isn’t sustainable. formal english is a barrier but requirement for specification. brevity is the language of money and that’s the premise of management using ai. fyi language alone can’t define/describe requirements which is why UML existed.
  • ako 5mo ago
    I think uml exists to help humans understand and communicate specifications, not because language alone is insufficient.
    • null_ptr1 5mo ago
      I mean, if you can't agree on what UML is, then what hope do you have to agree on what the spec says?
  • jstanley 5mo ago
    Natural language is a fully general system and can define and describe everything. You could deterministically process any UML diagram into a prose equivalent. And in fact you couldn't do the other way around (any prose -> UML) because UML is less powerful than natural language and actually can't express everything that natural language can.
    • rzzzt 5mo ago
      There are also diagram notation languages and LLMs are happy to both consume and produce e.g. Mermaid.
    • hansmayer 5mo ago
      > can define and describe everything. Can it also fully describe a composition by Bach or a Rembrandt's painting? In some weird, overly complex way it probably 'could', but it would be very painful. That's why we pick other forms of expression. We use other forms of expression to compact and optimise information delivery. Another benefit is that we cut out the noise. So yes UML cannot describe everything natural language can, but then again why should it - it was designed as a specific framework for designing relations between objects. Not more and not less. Similar for sequence diagrams or other forms of communicating ideas efficiently.
• wismwasm 5mo ago
  Try openspec: https://github.com/Fission-AI/OpenSpec/blob/main/docs/getting-started.md https://github.com/Fission-AI/OpenSpec/blob/main/docs/gettin...
  • arikrahman 5mo ago
    That was my initial thought when reading the headline but the author states they didn't know it existed before doing this project and critiques it.
  • brendanmc6 5mo ago
    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.
• wesselbindt 5mo ago
  I'm still confused as to why folks don't just write executable specs.
  • cenamus 5mo ago
    So basically tests?
    • MoreQARespect 5mo ago
      Yes, except a test can be turing complete - i.e. code. An executable spec like gherkin or hitchstory is config - it has no loops or conditionals. There are a number of rarely recognized benefits to this.
  • carlbarrdahl 5mo ago
    Could you expand on this?
    • booi 5mo ago
      code
      • arikrahman 5mo ago
        Literate programming would provide specs and code instead of working backwards from hard coded functions to figure out specs.
        • cassianoleal 5mo ago
          > working backwards from hard coded functions to figure out specs. People do that? Actual professionals?
          • arikrahman 5mo ago
            Yes all the time actually, especially when making system migrations. Uncle Bob writes about this in Clean Code. It is actually extremely common since it's the most apparent course of action to look at hard-coded values in maintenance and backport it as specs to new system.
• arikrahman 5mo ago
  I use OpenSpec for my spec management, and I scrolled down to the comparison. The gripe seems to be with a semantic difference. Specs describing a current system is the basis for AS/IS Gap Analysis. Also, I mainly pursue these tools so that I can have AI accelerate this process and broker an agreement after negotiating specs with the agent.
  • energy123 5mo ago
    I can see one benefit to a structured yaml for specs like the OP is doing: it gives you more control over what you include in the context window. But coming up with a good schema that doesn't handicap you or add cognitive burden, compared to the freeform flexibility of md/txt, is a challenge.
    • arikrahman 5mo ago
      If the selling point is a new file format for spec management, it would be more interesting to provide an offering with org-mode. The author admits they were unaware of other pre-existing solutions before this project so I am providing context to their critique of OpenSpec.
  • jochem9 5mo ago
    I'm also doing openspec for a few months now and it's really good if you invest enough in the specs (in the beginning I skimmed over much, now I pay attention to all details and fix anything that's wrong or where I see a gap). The one thing I like that OP brings is to tie specs and code together. The openspec flow does help a lot in keeping code synced with specs, but when a spec changes, AI needs to find the relevant code to change it. It's pretty easy to miss something in large codebase (especially when there is lots of legacy stuff). Being able to search for numbered spec tags to find relevant bits of code makes it much more likely to find what needs to be changed (and probably with less token use too).
    • alasano 5mo ago
      I enjoy the OpenSpec format but I think maintaining the main specs is not worth it. I've stopped doing it entirely and just archive directly after implementation. When you do the sync process, it just keeps drifting and drifting until you have duplication and contradictions across specs. I agree that tying the specs and code together helps for that but it still seems like extra overhead, even if the value is better justified here.
• colinmarc 5mo ago
  Wow - I love programming in YAML! You know what would make this really fun? Sprinkle in some Jinja. Then we'll be cooking with gas.
  • photios 5mo ago
    Dreaming about ` | nindent 12` in my specs! :D
  • grunder_advice 5mo ago
    Exactly. At some point, the specification becomes so complex, it's easier to just write the code yourself. It's why famously, programmers always say, the code is the documentation, because writing detailed docs is very tedious and nobody wants to do it.
    • bonesss 5mo ago
      There are middle-ways. Behaviour Driven Development or Spec Driven Development are, loosely, forms of Test Driven Development where you encode the specification into the code base. No impedance, full insight, formality through code. I think people get really dogmatic about “test” projects, but with a touch of effort a unit test harness can be split up into integration tests, acceptance tests, and specification compliance tests. Pull the data out as human readable reports and you have a living, verifiable, specification. Particularly using something comparable to back-ticks in F#, which let test names be defined with spaces and punctuation (ie “fulfills requirement 5.A.1, timeouts fail gracefully on mobile”), you can create specific layers of compiled, versioned, and verifiable specification baked into the codebase and available for PMs and testers and clients and approval committees.
  • hansmayer 5mo ago
    :) Here is a crazy thought - what if we had some kind of a narrowed down, specific subset of normal language which would translate into specific computer-level instructions. So for example, instead of telling computer to read something from a file and transform it in a certain way, you actually had a specific instruction to open a file, which worked the same each time you used it and guaranteed to fail if you used it the wrong way? Wow, the possibilities are endless :)
• augment_me 5mo ago
  Completely subjective take, but I feel like 95% of these "tools" that are prompt-engineering inventions created by the authors with their bias and to suit their needs don't have anything supporting them besides the authors' subjective experience. I have seen the same idea with processes, pipelines, lists, bullet points, jsons, yamls, trees, prioritization queues all for LLM context and instruction alignment. It's like the authors take the structure they are familiar with, and go 100% in on it until it provides value for them and then they think it's the best thing since sliced bread. I would like, for once, to see some kind of exploration/abalation against other methods. Or even better, a tool that uses your data to figure out your personal bias and structure preference for writing specs, so that you can have a way of providing yourself value.
  • IceDane 5mo ago
    It's like horoscopes for the entirely-too-AI-pilled. Founded in nothing but vibes. "Don't write prompts like that, do it like this! I swear it's better. Claude says so!"
  • sunaookami 5mo ago
    It's Vibesmaxxing
  • hsaliak 5mo ago
    nobody knows what to build when everything can be built, there is no moat.
  • Yokohiii 5mo ago
    The inherent lack of distinction for LLMs between code, structured formats and natural language is ridiculous. Before the AI era we had a trend to increase type safety everywhere. Now we just sling code and natural text around and hope it works.
• photios 5mo ago
  Yesterday I heard about lat.md [1] which seems to have similar ideas about annotating code with spec refs. I now need to try them both. [1] https://www.lat.md/ https://www.lat.md/
  • arikrahman 5mo ago
    Agents.md actually scales and outperforms alternatives so I would be skeptical about overcomplicating the proces https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
  • brendanmc6 5mo ago
    Oh cool, thanks for sharing. LLMs tend to adopt these patterns on their own, so I'm sure my ideas are far from unique.
• jwpapi 5mo ago
  And once you’ve written all these specs you realize it became so slow that it’s faster to do it yourself in editor
  • motoxpro 5mo ago
    at which point you realize you never had a plan written down and you are using the code as a spec
    • jbjbjbjb 5mo ago
      Which takes us back to this: https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...
  • girvo 5mo ago
    People don’t actually track wall clock time, I’ve noticed.
    • oblio 5mo ago
      Nope, they never do. That's how you end up with those cooking recipes that only "take 5 minutes". Sure, if you don't count buying all the ingredients, cleaning and preparing them, cleaning up the pots and pans (and probably the worktop, stove, etc), a lot of things can take 5 minutes. Even trivial stuff like scrambled eggs don't actually take 5 minutes when you take everything into account. Reminds me when I automated a manual service deployment that only "took 5 minutes". Sure, copying the binaries only took 5 minutes, but coordinating between various departments to deactivate the relevant monitoring bits, turning off the services, invalidate the caches, etc, etc actually took half a day with humans involved. Once automated and parallelized the thing took about 10 minutes for a data center.
  • wiseowise 5mo ago
    But have you thought about “fun factor”? It’s where you sit like an addict in a casino for weeks and burn tokens in a hope of winning a software that you could’ve written? Who doesn’t consider “fun” thinking about work crap all the time, writing to your agent, verifying walls of slop?
• ltbarcly3 5mo ago
  Grindmaxxing, a long form blog post that is actually just an advertisement for his website.
  • brendanmc6 5mo ago
    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.
    • hansmayer 5mo ago
      Read the room. What you "built" is neither exciting, nor something most people want to "try". Why? Because just like other AI boosters, you are still trying to somehow optimise the usage of natural language to make it work. But it will never "work" because the way the stochastic ML system is built, it has a failure built into the system.
      • brendanmc6 5mo ago
        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.
        • hansmayer 5mo ago
          > Failure-prone stochastic ML systems produce testable, auditable code... You're missing the bigger picture here. Yeah, they produce code. But "producing" code was never the bottleneck. Yes you can pop out a webapp within a couple of hours, but now you have no clue how it works, even if its a language and framework you are competent it in, because you skipped the part where you understand how the parts fit in together architecturally. So you wrote an elaborate spec, but the LLM "decides" to do something else. Maybe they don't make that PK autoincrement or they throw you in those nice empty "catch" blocks they ingested from various beginner tutorials, which will be very "helpful" when you application silently deviates from the happy path execution that you spec'ed the hell out of in your virulent spec-driven-workflow.. So it "kinda" works, it generates the code. It works the way your kid's toy car works - it "drives" but it cannot be driven to work, can it? So it does not work in the big picture. It's not a reliable enterprise ready system. It's a toy, and should be treated like one.
• zarzavat 5mo ago
  YAML is one of the worst technologies ever invented, it has more warts than features. One of the benefits of LLMs is that they can write YAML for me, wherever I am forced to use it. Otherwise, I like the idea of machine-readable specs.
• deleted 5mo ago
  [deleted]
• jFriedensreich 5mo ago
  Where is the part where the author overcomes ai psychosis? Reads like digging in deeper and deeper.
  • wiseowise 5mo ago
    That’s the best part: you don’t. “You would extend the prompt to improve it”. They’ll just ask Claude to write an AI tool to overcome psychosis (the program will spam Anthropic servers with racial slurs which will promptly cause ban of the user, success).
  • brendanmc6 5mo ago
    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?
    • aliceryhl 5mo ago
      This is not psychosis.
    • dgellow 5mo ago
      I don’t understand how that relates to AI psychosis?
      • khalic 5mo ago
        Some people seem to give very little thought to semantics and semiotics lately, to the point where people use words vaguely without even looking it up.
• mrbnprck 5mo ago
  Could it be that slop PRs are less frequently rejected/commented due to (unfortunate) increased acceptance of it? As it turns out when maxxing AI on leaf parts of a program, the quality of the code doesn't matter that much anymore when compared to building the fundament.
• hansmayer 5mo ago
  > We are entering the post-slop era. My software is more robust, better tested, better integrated, and more observable than ever before. And my velocity keeps increasing! Don't we just love the hard fact conclusions based on sample size N=1 and hand-waving arguments?
  • wiseowise 5mo ago
    They’re at the forefront of the industry. Catch up, slowpoke!
    • hansmayer 5mo ago
      Yeah. Waiting to be left behind...since 2020...
• jeffreygoesto 5mo ago
  Old ist new I guess. This is independent of whether A"I" or a human executes, the point is that you need this if specifying and execution lie apart, be it in time or space. This is basically the whole point of the V-Model and processes (if used correctly as a tool and not preferred as goals) and was already researched an formalized in the 60s and 70s.
• imiric 5mo ago
  I'm tired, boss. This industry has become a parody of itself, and people are celebrating.
  • brendanmc6 5mo ago
    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.
• wiseowise 5mo ago
  What is it with people and procrastinating with the most useless shit you can imagine? First it was choice of editor: people were micro optimizing every aspect of their typing experience, editor wars where people would literally slaughter over suggesting another camp. Editor wars v2: IDEs arrived and second editor war began. Revenge of the note taking apps: Obsidian/Roam/Joplin/Apple Notes/Logseq. Just one plugin, just one more knowledge graph, bro, and I’ll have peak productivity. 10x is almost here. AI: you’re witnessing it now. Do people NOT have anything else in life? How are y’all finding time to do all of this shit? Are you doing it on company time? Do you have hobbies, do you learn foreign languages, travel, have kids or spouses, drive a car, other thousand “normie” things outside of staring at the freaking monitor or thinking about this shit 24/7? Did I miss the invention of a Time Machine?
  • geoffbp 5mo ago
    I think people find joy in trying to optimise (maxxxxxx) their setup be it editor AI note taking etc. They make time for it
  • logicchains 5mo ago
    >Do people NOT have anything else in life? How are y’all finding time to do all of this shit? Are you doing it on company time? Do you have hobbies, do you learn foreign languages, travel, have kids or spouses, drive a car, other thousand “normie” things outside of staring at the freaking monitor or thinking about this shit 24/7? Did I miss the invention of a Time Machine? How are any of those things even remotely as interesting as arguing with people about an Emacs config?
    • WesolyKubeczek 5mo ago
      If you have ever been to car forums, it's quite the same there. People are people.
  • hansmayer 5mo ago
    A lot of people sadly, nowadays don't have anything resembling to a social life and family... So here we are now, specmaxxing and shit :)
• taffydavid 5mo ago
  I just spent a week training up in spec driven development through bmad, which was awful, and speckit which was ok but not great. Both had what seemed like unnecessary ceremony around the specs, generating fields of spec documents which presumably fill up the context window quickly. I just kept thinking "this should be using something simpler, all this markdown is unnecessary" This seems like the answer to that thought!
• stevefan1999 5mo ago
  So...is this just Cucumber cough cough behavior driven design again, but stored in YAML so that LLMs can read it easier by loading the AST instead of tokenizing the text?
  • spopejoy 5mo ago
    OMG I forgot all about cucumber, but wow the "cucumber cycle" of old sounds a lot like LLM psychosis of today. As in, the solution to cucumber problems was always to invest more into cucumber! Add more operations! Integrate more things into it! Did cucumber go away? I never hear about it anymore.
• TheServitor 5mo ago
  ugh with the "maxxing" everything
  • gverrilla 5mo ago
    it's 4chan/incel language. ugh indeed
• wasabinator 5mo ago
  More nonsense buzzword soup de jour. Can I play along at home? How about Vibewatermaxxing? Surely in the new age it should catch on. This industry is just getting more and more bonkers.
• lifeisstillgood 5mo ago
  I also have started numbering my Acceptance criteria and pushing that across the team(s). It’s going pretty well. Some note however are 1. Don’t write in yaml. It’s really hard for humans. Write in markdown and use a standard means to convert to lists / yaml. 2. Think beyond you writing your own specs - how does this expand into teams of tens or more. The ticketing system you have (jira? Bugzilla) is not designed for discussion of the acceptance criteria. I think we are heading into a world of waterfall again where we have discussions around the acceptance criteria. This is not a bad thing - is used to be called product management and they would write an upfront spec. If this new world of a tech and a business user lead the writing of a new spec (like a PEP) and then then AI implements it and it’s put into a UAT harness for larger review and a daily cycle begins, we might have something. Good luck
• k9294 5mo ago
  Small advice - make one repo “main” and link to it from the website instead of an organisation. I wanted to star the project to track the progress but it feels a bit weird.. Which repo shall I track? Server? Cli? Sounds like a misc repos.
  • brendanmc6 5mo ago
    Ooh thought I did that, thanks.
• opengears 5mo ago
  There are also Architectural Decision Records (ADRs), which might be something similar. https://adr.github.io/ https://adr.github.io/
  • 0123456789ABCDE 5mo ago
    some folks also refer to these as PRODUCT decision records
• k9294 5mo ago
  What is yours agentic development experience with elixir? I used to like elixir a lot during a pre agentic era, but with coding agents it feels like the language isn't the best choice - slow compile time, weak type system (at least it was a year ago, I know there is work on that front), small ecosystem...
  • chickensong 5mo ago
    I find agents work well with Elixir, but you should reach for it when the product benefits from Elixir/BEAM features. A slow compile time is a minor annoyance compared to the greater architectural decision. Elixir hot-reloading with Tidewave works well for agent loops though.
• pineaux 5mo ago
  Anything [prefix]maxxing just sounds so bad. It just feels so Andrew Tate...
  • ashleyn 5mo ago
    It's more Clavicular than Andrew Tate.
• teekert 5mo ago
  It’s like a yaml of an event model but less graphical. Right? I think I will prefer Event Modeling especially with Martin Dilger now building tooling very much with agents in mind. There is no one place to read about his most recent efforts except for his LinkedIn feed though I fear.l so won’t post any urls, but information is easy enough to find. A full blown event model facilitates all communication, human (management, devs, ops) and agentic. But maybe I’m missing something, maybe the dashboard can have this function I didn’t dig into it too much.
• GRMPZ23 5mo ago
  [dead]
• dotneter 5mo ago
  I didn’t quite understand why YAML is better than Markdown for such specifications. If the specification is written in such a strict format as YAML, I would expect it to be executable, something like this https://blog.fooqux.com/blog/executable-specification/ https://blog.fooqux.com/blog/executable-specification/ But as far as I understood, for acai that is not the case.
  • csomar 5mo ago
    It's not. And LLMs don't do well with YAML either. I've had the agent/model struggle with `sed` trying to count how many spaces are in there multiple times to get the file to pass. It's the worst format you can use for LLMs.
  • brendanmc6 5mo ago
    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. ```
    • dotneter 5mo ago
• cube2222 5mo ago
  Love the writing style! > Nothing beats an organic, pasture-raised, hand-written spec. Hah, I strongly empathize with the wording. I’ve been starting my design docs for fellow humans with “100% hand-written, organic content”, I might steal a part of yours. Overall, cool idea. I don’t see myself using your SaaS, but the approach of tagging the requirements and constraints to make them easier to find sounds good. One project you didn’t mention which I think is also, I think, a cool perspective on this is codespeak.dev , but I haven’t given it a go yet. All in all, I feel like maintaining specs, and having agents translate spec diffs into code diffs is a promising area for the future. Good thing I enjoy writing!
• didgeoridoo 5mo ago
  I’m building something similar with https://github.com/LabLeaks/special https://github.com/LabLeaks/special (apologies for the desultory slop-laden README, need to give that a lot more human attention) but I’ve gone in a slightly different direction: a “spec” is a product contract claim supported by attached tests that verify it. It’s a little Cucumber-y, if anyone remembers that, but a lot more flexible — you just write stuff like @spec LINT_COMMAND.ORPHAN_VERIFIES linter reports blocks that do not attach to a supported owned item. Then #[test] // @verifies SPECIAL.LINT_COMMAND.ORPHAN_VERIFIES fn rejects_orphan_verifies_blocks() { let block = block_with_path("src/example.rs", &["@verifies EXPORT.ORPHAN"]); let parsed = parse_current(&block); assert!(parsed.verifies.is_empty()); assert_eq!(parsed.diagnostics.len(), 1); assert!( parsed.diagnostics[0] .message .contains("@verifies must attach to the next supported item") ); } And then the CLI command “special specs” pulls your specs and all attached verification + test code so you (or your LLM) to analyze whether the (hopefully passing!) test actually supports the product claim. There’s also a bunch of other code quality commands and source annotations in there for architectural design & analysis, fuzzy-checking for DRY opportunities, and general codebase health. But on the overall principle, this article is dead-on: when developing with LLMs, your source of truth should be in your code, or at least co-located with it.
• jimmypk 5mo ago
  [flagged]
• SirFatty 5mo ago
  Stopped at "Specsmaxxing".
  • dare944 5mo ago
    Right? Just gross...
• _the_inflator 5mo ago
  The author is right but his message ain’t specsmaxing, because while somewhat understandable as a rationale what does it actually mean? In other words: specs can be as detailed as it gets, and this is why developers have a hard time when they face as a senior an NDAed regulated environment. It ain’t software craftsmanship but data flow, hardware components, compliance on the lowest level including supply chains often times, information architecture - a simple app needs to comply to specs that amount to thousands of pages. Context window: circular reference. A year ago? Specsmaxing by really weeding out any redundant words. Today? Yawn, like with 8mb RAM vs 512 Gigabytes. AI wants to be easy on us so what is a spec anyway then? To put it this way: the spec for the spec is constantly evolving. Last year’s prompts lead to extremely different results today no matter how maxed out. The author was on point with his introduction: AI is as junior in many ways when it comes to any sort of efficiency and optimization. This is my revaluation after years of experimenting with AI. Beautiful code, sophisticated but performance wise and its architecture are laughable at best. AI is not trained on optimization. Not the slightest and juniors have no clue about algorithms and Big O. In fact Google used Big O as a basic entry level interview question for a very long time. They have to but the simple fact that in my experience 99% of devs never heard or consider it speaks volumes. AI cannot compensate for that (yet). I went the opposite and my specs focus heavily on architecture and the obvious dumb performance drains noobs do. Google was mocked about Big O. And yes, failing to understand that Big O can be neglected thankfully in 99% of cases is part of its logic. AI bloats your code. And a year long single dev project gets pumped out in hours. In short: a homerun for Big O because it looks on results that change depending on the variables. A function in mathematical terms. So I think the author did a funny and great job of you focus on Big O if needed. Everything else is not that important because of being open to change and extension. Big numbers need great architecture. It screams loudly. And also think about leaks. Before AI I had virtually no memory leaks at all. Since AI NodeJS and React are worse leaking compared to IE 6 and 8. I mean it. Big O reduces them significantly, so don’t work around the Elephant in the room. Architecture and optimization is brutally hard. Google blew my mind in this regard but this is another story of squeezing out even milliseconds out of a build tool used by all. A single dev laughs at it but failed the calculation as well as abstraction.
  • deleted 5mo ago
    [deleted]
• ffsm8 5mo ago
  Why is the vibecoding crowd still holding onto the idea that markdown (or here yml) is a better spec then code? Seriously, it's just not Write your code like it's your spec and your software will be more stable, maintainable clearer to read. Code is not transient, it is your friggin spec itself And if your code isn't structured like it's a spec, then your code is garbage from the perspective of LLM driven development
  • anonzzzies 5mo ago
    Most 'programmers' cannot read or write code very well (or reason about structure or architecture) and so they want to 'program in english'.
    • yuye 5mo ago
      This has been attempted for as long as programming has existed.
      • anonzzzies 5mo ago
        Sure but now it actually works somewhat.
  • deleted 5mo ago
    [deleted]
  • zbyforgotp 5mo ago
    The idea is that the spec is somehow compressed in comparison to the code.
  • brendanmc6 5mo ago
    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.
• csomar 5mo ago
  Dear Claude, I hope this email finds you well.\ I am writing to ask if you could please do another task for me.\ Start by running \`npx @acai.sh/cli skill\`.\ This will teach you everything you need to know about our process for spec-driven development. Then, proceed to plan and implement the features specified in our spec files. Love,\ \[your-name] Honestly, I can no longer tell parody from reality. Whether in politics or AI.
• foobarbecue 5mo ago
  Unfortunate name collision between your ACID concept and the database principles (atomicity, consistency, isolation, durability).
• tokenhub_dev 5mo ago
  [flagged]
• jnpnj 5mo ago
  looks like an informal DSL for specs that brings back some quantifiable structure, how many people follow the same ? also, i wonder if people who did MDD (model driven development) have embedded AI in their methodology
• hsaliak 5mo ago
  the problem is not the forward pass, its the control/feedback loop when slop is written in response to the forward pass. Perhaps we should give the LLM 2 specs, one designed for the forward pass and another for the acceptance criteria /backward pass that's focused on tests, best practices and code, so that the output is independently verified?
• matthova 5mo ago
  Generally excited to try it out. The only thing that gives me pause is the idea of asking Claude to install a specific package. I know this is a bit naive as I’m probably downloading so many other things without my knowledge, but planning to read/fork the source before running any install commands
  • brendanmc6 5mo ago
    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 https://github.com/acai-sh/cli/blob/main/docs/security.md
• smokel 5mo ago
  Quite some people here dismiss requirements engineering as something non-agile and ancient. If you are in this camp, consider educating yourself a bit on the V-model [1] and notice that this is not only used in the waterfall model, but that it is a way to decompose problems and verify that everything works properly. This may not be required for a small hobby project, but if you start working at something with multiple companies in various technologies, it soon becomes extremely useful. [1] https://en.wikipedia.org/wiki/V-model https://en.wikipedia.org/wiki/V-model
• clbrmbr 5mo ago
  I’ve had great success structuring requirements using Johnny Decimal. Well organized and numbered requirements for each project is mega helpful for agents and humans throughout the progress. Oh and I love açaí.
• sailfast 5mo ago
  This seems like circling around the same problem: AI just misses things sometimes and the things it misses can end up being really important. If you don’t cross-check it, you’ll have a bad time. I’ve used a couple of different skills libraries for this - most recently “super powers” which builds a detailed markdown plan and then uses TDD for most parts. Not sure converting to YAML and running an app to track beats Linear tickets or a local cache or markdown if I’m honest but if it works for you and your process that’s great! Mainly I don’t think everyone building their bespoke solution needs to try and create a product out of it. If it works for you, maybe good enough. Focus on your process before you worry about generalizing these days.
• chrisldgk 5mo ago
  At this point, why not just write the code yourself? Defining exactly what the product is supposed to do is the hard part, writing code is the easy part. Write your specs as code and you have your product - why let your LLM do the fun part?
  • Stehfyn 5mo ago
    Just because I am capable of "writing all that code", doesn't make the option preferable to defining a vast majority of spec up front and having an LLM generate an implementation. I am already going to spend the brain power on reviewing the code. I am already going to spend the brain power on pontificating edge cases, external module interactions, and next steps. Why not fast forward to that point and save 80% of the time (and brain power/attention/motivation to boot)?
    • BoredPositron 5mo ago
      Not a developer would come to mind.
    • codebolt 5mo ago
      I'm with you all the way here. I derive zero pleasure from simply typing out the code once the spec is clear. Having a fast forward button to skip that phase is a pure win in my book.
      • jaredcwhite 5mo ago
        100% the opposite here. I derive all the pleasure from writing code, which is why I'm still writing code.
      • sigmonsays 5mo ago
        a spec can be wrong until you prove it is right..
      • honr 5mo ago
        I do get pleasure from typing out the code in some languages (and not in others; hello javascript, java!). Similarly, I love writing text with a calligraphy or fountain pen. However, I can't dedicate too of the much work / business time to whatever is more pleasurable. So, I "doodle" some text / ideas / planning with a calligraphy pen, and type in some code, occasionally, both mainly for the fun aspects. There are side benefits to both, too. Writing some plans slowly and "beautifully" drags them out and I get to think longer on them, so the sporadic "nice looking plans" are often more well thought. And doing the coding all by myself stops my brain from losing the ability. I was initially in the 100% AI-writes-all-code camp for a while and noticed I am getting notably slow in some personal coding skills. It is too early to treat specs as the new code and old languages as assembly (but I admit we might get there some day). In other words, I think AI doing 90-99% of the coding, depending on the language verbosity and AI accuracy for the code at hand, is quite reasonable.
• DeathArrow 5mo ago
  When developing large or complex software with AI, I think we need kind of a "Jira for coding agents" - something that is much lighter and simple than Jira, where agents can see the specs, see what is completed, what is the relationship between different features and what needs to change. That would be easier to use than gazillons of .md files and skills.
• cabnm 5mo ago
  I don't think the manic tone of the blog post is an indication that overcoming AI psychosis has worked in any way.
• felooboolooomba 5mo ago
  Anything ending in "maxxing" will be seen as a joke, treated with contempt or both. The poor guy is livestreaming his acute body dysmorphic disorder. Social media is making money off him and we're all either laughing or astonished.
  • esseph 5mo ago
    > Anything ending in "maxxing" will be seen as a joke, treated with contempt or both. Always was. > Social media is making money off him Yes, and he's been making a TON of money as well. > and we're all either laughing or astonished So social media, got it. Social media LOVES controversial assholes, they just keep making money hand over fist (look at the Paul brothers for example).
• fwipsy 5mo ago
  AI psychosis is literal psychosis in humans associated with AI use. I don't think the author is psychotic? We have all these useful new terms for AI phenomena, if we can keep them straight...
  • brendanmc6 5mo ago
    Fair critique, voiced elsewhere in this thread as well, I am regretting my use of the term.
    • itopaloglu83 5mo ago
      I absolutely understand that, because that response puts me in one after a couple times. > You’re absolutely right! Let me fix that.
• deleted 5mo ago
  [deleted]
• docheinestages 5mo ago
  I think the whole point of using an LLM is so that you don't have to write your spec in a specific language. Sure, spec-driven development makes sense, because you need to specify how and what you exactly want to build, test, and ship. But writing specs in YAML is really swimming against the current.
• natyoung 5mo ago
  The 4-tier test structure set out in the Continuous Delivery book (from 15 years ago) already does this better.
• ejoubaud 5mo ago
  how would you go about adopting this on a brownfield project? Are agents good at deriving the spec from the code? If so do you find the derivation adds much value?
  • michaelrpeskin 5mo ago
    Recently I did something similar to this on a small part of a project that has built up organically over a couple of years. One developer was getting the output of one program (that we didn't control) into one of our systems. So he wrote a python parser to read the output and put it in a structured format for us to read. Over the years edge cases and options kept creeping in, small features were added one at a time and it kept working. We had to migrate to a new customer who didn't want the python middle layer, they wanted our software (Java) to read the output directly (don't argue on why this was necessary, just a requirement from a big customer). Since the python script grew up over time by many developers with small changes for new features, it was nearly impossible to understand exactly what it was doing. I took only the parser code gave it to Opus 4.7 and said "This python code parses an undocumented file format. All of our tests pass and this code is the spec for the file format. Read the python code and create me a BNF document that describes what it parses." I took the BNF and started a new session and said "write me a parser in Java that parses the grammar in this BNF." It got it in one shot. Then all I needed to do is take what was parsed and pipe it into our existing software that took the structured format the python created. Most of what I do is brownfield work and I really can't put our whole code base into an LLM because of IP issues, but for little things like this, is saves me weeks of work.
• martythemaniak 5mo ago
  There's a lot of people wondering "Why not just do this all in code", to which there is a very simple and straightforward answer: compression. An LLM/agent can take 100 tokens worth of spec and turn it into 1000 tokens worth of code. We all understand this well enough in the most basic case: you type a one line comment and the LLM will give you the correct 10 line function. But this scales - 10 line comment into 100 line function, 100 line spec into a 1000 line object etc. Depending on the work, you could get more or less than 10x compression. The disagreements are all largely "what what level of resolution should devs be operating", my opinion is that the current sweet spot it roughly 1000 tokens of spec (~750 word doc/3 pages) producing 10000 tokens (~1000loc) This compression allows your spec to be much denser and more readable than raw code. It can be shared, understood and modified by non-dev partners more easily, gives you flexibility into how it's implemented etc.
• physicles 5mo ago
  From the perspective of the “physics” of code (for lack of a better term), this feels right. We all know that if you have a generated asset, you basically mark that asset as read-only or you’re entering a world of pain. As more and more code is generated, the same forces will apply. Harder for brownfield projects of course (and it basically replaces Jira, which would cost me all my social capital if I try), so I won’t be adopting it now. But I will be leaning into long-lived organic, grass-fed assets like conceptual-model.md that‘s critical for evolving the product forward but doesn’t strictly map to the types in the code. I really enjoyed engaging with the article. Loved the humor sprinkled in, and the humility demonstrated throughout. Some great first-principles clear thinking here.
• pshirshov 5mo ago
  https://github.com/7mind/nix-config/blob/main/pkg/llm-prompts/skills/review-loop/content.md https://github.com/7mind/nix-config/blob/main/pkg/llm-prompt... - this does the same job and requires nothing.
• hintymad 5mo ago
  Maybe it's just me, but isn't it exhausting that we have to do all kinds of work like a Shaman to combat the probabilistic nature of LLM, while knowing from the bottom of our heart that LLM can still screw up the code in the most creative way?
  • akomtu 5mo ago
    AI makes us believe that instead of working towards a goal, one can "win" that goal with a lucky prompt. AI replaces thinking with gambling, in other words, and it's very tempting to many.
• plazmod 5mo ago
  [dead]
• tommica 5mo ago
  One thing that popped to my mind from this article is code comments; crazy idea, what if any piece of code had to justify its existence - comment explaining why it is there and in support of what feature. I want to try this features.yaml approach - there is something solid there, and the acai.sh tooling looks nifty.
• deleted 5mo ago
  [deleted]