241–250 of 316 posts
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.
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?
Code lacks the surrounding theory that situates the code in the world [1]. My specs contain the theory that the code lacks, which makes specs more valuable in the future. Specs are proprietary data. Data holds value in a post-AGI world, not code.
I am defining specs to be more than just an architectural spec, to me it's more like I'm writing a booklet about a subject, and I'm using it to teach the LLM via in-context learning. It might need a different word than "specs".
Earlier quoted context omitted.
> I am already going to spend the brain power on reviewing the code. Very few devs are actually reviewing any generated code. > Why not fast forward to that point and save 80% of the time If you are saving 80% of time, you aren't actually reviewing the code.
> Very few devs are actually reviewing any generated code. Just because very few devs are qualified at doing their fucking job, it doesn't make someone trying to use AI properly wrong. > If you are saving 80% of time, you aren't actually reviewing the code. The idea is that if you spend time in specification ahead of time, reviewing and validating will be easier and less time consuming later. I haven't tried it mysel…
Hell, you probably couldn't even build a simple bike shed from plans without having to revise them while building, so I am skeptical that without writing you are going to pinpoint the problems in the spec.
Reading only gets you a short way towards learning.
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?
I do this because I'm wagering that LLMs will keep getting better. I'm wagering that specs will maintain value while code will degrade in value (become commoditized). Code lacks the surrounding theory that situates the code in the world [1]. My specs contain the theory that the code lacks, which makes specs more valuable in the future. Specs are proprietary data. Data holds value in a post-AGI world, not code. I am d…
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?
There is a massive difference between a spec, which defines what the product should do, and code, which defines exactly how it should do it. Moving from the former to the latter is not "the easy part". Anyone who genuinely believes that either works on easy and straightforward problems, or is some sort of programming god. Because translating specs to code can still be difficult and exhausting.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
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?
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.
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.
Earlier quoted context omitted.
There is a lot of room to reevaluate the lessons of software development pre-web in the context of the current environment. Like, if waterfall of a project can be done in 2 weeks, is it agile now?
> Like, if waterfall of a project can be done in 2 weeks, is it agile now? Sure. The thing is, the waterfall guys would tell you it's impossible to do it in 2 weeks because you need to have written down everything first . "Thousands of pages" was the terms they used. Agile guys would point you to the Agile manifesto which would lead you to "working code over documentation" and "people over process". A 2 week period t…
- System/Segment Specification
- Software Development Plan
- Software Configuration Management Plan
- Software Quality Evaluation Plan
- Software Requirements Specification
- Interface Requirements Specification
- Software Standards and Procedures Manual
- Software Top Level Design Document
- Software Detailed Design Document
- Interface Design Document
- Data Base Design Document
- Software Product Specification
- Version Description Document
- Software Test Plan
- Software Test Description
- Software Test Procedure
- Software Test Report
- Computer Sytem Operator's Manual
- Software User's Manual
- Computer System Diagnostic Manual
- Software Programmer's Manual
- Firmware Support Manual
- Operational Concept Document
- Computer Resources Integrated Support Document
- Configuration Management Plan
- Engineering Change Proposal
- Specification Change Notice