Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Software Development Methodology for Disciplined LLM Collaboration

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: A Software Development Methodology for Disciplined LLM Collaboration

#21

Post by pydry »

grork wrote: post #18
perrygeo wrote: post #16

There's some irony; far from handling the details, LLMs are forcing programmers to adopt hyper-detailed, disciplined practices. They've finally cajoled software developers into writing documentation! Worth noting we've always had the capacity to implement these practices to improve HUMAN collaboration, but rarely bothered.

We’ve ultimately decided to treat the models with more respect, nurturing, and collaborative support than we ever did our follow human keyboard smashers. Writing all the documentation, detailed guidance, allowing them multiple attempts, to help the LLMs be successful. But Brenda, the early in career new grad? “please read this poorly written, 5 year-old, incomplete wiki, and don’t ask me questions” I’ve been thinking…

The halo effect around LLMs is something crazy.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#22

Post by 627467 »

perrygeo wrote: post #16

There's some irony; far from handling the details, LLMs are forcing programmers to adopt hyper-detailed, disciplined practices. They've finally cajoled software developers into writing documentation! Worth noting we've always had the capacity to implement these practices to improve HUMAN collaboration, but rarely bothered.

What i keep seeing missing for AI-labor replacement discussions is that technology may seem to replace human labor, but it doesn't really replace human accountability.

Organizations many times seem capable to diffuse blame for mistakes within their human beaurocracy but as beaurocracy is reduced with AI, individuals become more exposed.

This alone - in my view - is sufficient counterpressure to fully replace humans in organizations.

Shorter reply: if my AI setup fails I'm the one to blame. If I do a bad job at helping coworkers perform better is the blame fully mine?

Re: A Software Development Methodology for Disciplined LLM Collaboration

#23

Post by jemiluv8 »

Reminds me when I was demonstrating Claude code to a friend recently. My friend was a huge cursor user and was just curious about the cli tool and stuff.

In the end, regardless of framework or approach, I believe there is a way to go about using llms that will optimize work for developers. I worked with this tech lead who reviews all PRs and insists on imports arranged in a specific order. I found it insulting but did it anyway. Now I don’t - the not does.

The same way that llms can be really helpful in planning and building out specific things like rest endpoints, small web components, single functions or classes and so on.

Glad people are attempting to work on such potential solution for approaching work to take advantage of these new tools

Re: A Software Development Methodology for Disciplined LLM Collaboration

#25

Post by henrebotha »

grork wrote: post #18
perrygeo wrote: post #16

There's some irony; far from handling the details, LLMs are forcing programmers to adopt hyper-detailed, disciplined practices. They've finally cajoled software developers into writing documentation! Worth noting we've always had the capacity to implement these practices to improve HUMAN collaboration, but rarely bothered.

We’ve ultimately decided to treat the models with more respect, nurturing, and collaborative support than we ever did our follow human keyboard smashers. Writing all the documentation, detailed guidance, allowing them multiple attempts, to help the LLMs be successful. But Brenda, the early in career new grad? “please read this poorly written, 5 year-old, incomplete wiki, and don’t ask me questions” I’ve been thinking…

I would also be motivated to write better documentation if I had a junior dev sitting right next to me, utterly incapable of doing any work unless I document how; but also instantly acting on documentation I produce, and giving me rapid feedback on which parts of the documentation are sending the wrong message.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#26

Post by UncleEntity »

jay-baleine wrote: post #17
gravypod wrote: post #11

Earlier quoted context omitted.

> The PhiCode runtime for example - a complete programming language with code conversion, performance optimization, and security validation. It was built in 14 days. The commit history provides trackable evidence; manual development of comparable functionality would require months of work as a solo developer. I've been looking at the docs and something I don't fully understand is what PhiCode Runtime does? It seems l…

Your four points are correct: 1. Symbol mapping: Yes - ƒ → def, ∀ → for, λ → lambda, π → print, etc. Custom mappings are configurable. 2. Multi-layer caching: Confirmed - source content cache, transpiled Python cache, module import specs, and optimized bytecode with batch writes. 3. PhiRust acceleration: Clarification - it's a Rust-based transpiler that handles the symbol-to-Python conversion for performance, not con…

> Where AST parsing, transformation, and regeneration introduces overhead that makes real-time symbol conversion impractical for large codebases.

I don't really understand why you need to do anything different when using a parser than the regex method, there's no real reason to have to parse to an AST (with all the python goodness involved with that) at all when the parser can just do the string replacement the same as whatever PhiRust is doing.

I have this peg VM (based on the lpeg papers) I've been poking at for a little while now that, while admittedly I haven't actually tested its speed, I'd be amazed if it couldn't do 3Mb/s...in fact, the main limiting factor seems to be getting bytes off the disk and the parser runtime is just noise compared to that with all the 'musttail' shenanigans going on.

And even that is overkill for simple keyword replacement with all the work done over the years on macro systems needing to be blazing fast -- which is not something I've looked into at all to see how they do their magic except a brief peek at C's macro rules which are, let's just say, complicated.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#27

Post by kanak8278 »

Can anyone help me on how to integrate this with Claude-Code? I went through it, I already follow few things manually but when I think of integrating most of the parts (not all), I don't know where should I put it for the Coding-LLM to understand. I fear if I put everything in Claude.md it will be just too much context for the CC.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#28

Post by ares623 »

perrygeo wrote: post #16

There's some irony; far from handling the details, LLMs are forcing programmers to adopt hyper-detailed, disciplined practices. They've finally cajoled software developers into writing documentation! Worth noting we've always had the capacity to implement these practices to improve HUMAN collaboration, but rarely bothered.

I wonder if this is what will kill LLMs in the software development domain.

It turns out that writing and maintaining documentation is just that universally hated.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#29

Post by [deleted] »

CuriouslyC wrote: post #15
esafak wrote: post #6

Modern agentic tools already draw up plans before implementation. Some even define "plan" and "build" agents: https://opencode.ai/docs/agents/#built-in

Agents are really bad at planning, unless the agent is farming out the plan to a deep research tool, as your codebase grows things are gonna end badly.

[deleted]

Re: A Software Development Methodology for Disciplined LLM Collaboration

#30

Post by ianbicking »

perrygeo wrote: post #16

There's some irony; far from handling the details, LLMs are forcing programmers to adopt hyper-detailed, disciplined practices. They've finally cajoled software developers into writing documentation! Worth noting we've always had the capacity to implement these practices to improve HUMAN collaboration, but rarely bothered.

My experience writing in a professional setting is that people mostly don't read what I write, and the more effort I put into being thorough the less likely that it will be read.
Post reply on HN