A Software Development Methodology for Disciplined LLM Collaboration • Hacker News Board

Re: A Software Development Methodology for Disciplined LLM Collaboration

#11

Post by gravypod » Sat, Sep 06, 2025, 2:27 PM UTC

jay-baleine wrote: post #7

sublinear wrote: post #2

This may produce some successes, but it's so much more work than just writing the code yourself that it's pointless. This structured way of working with generative AI is so strict that there is no scaling it up either. It feels like years since this was established to be a waste of time. If the goal is to start writing code not knowing much, it may be a good way to learn how and establish a similar discipline within…

What tends to get overlooked is the actual development speeds these projects achieve. 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. The "more work" claim doe…

> 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 like:

1. Mapping of ligatures -> keywords (ex: ƒ -> def).

2. Caching of 3 types (source content, python parsing, module imports, and python bytecode).

3. Call into phirust-transpiler which seems to try and convert things into rust code?

4. An http api for requesting these operations.

A lot of this seems to be done with regexs. Was there a motivation for doing string replace instead of python -> ast -> conversion -> new ast -> source? What is this code being used for?

Re: A Software Development Methodology for Disciplined LLM Collaboration

#12

Post by CuriouslyC » Sat, Sep 06, 2025, 2:30 PM UTC

sublinear wrote: post #2

This may produce some successes, but it's so much more work than just writing the code yourself that it's pointless. This structured way of working with generative AI is so strict that there is no scaling it up either. It feels like years since this was established to be a waste of time. If the goal is to start writing code not knowing much, it may be a good way to learn how and establish a similar discipline within…

It's not. I can get a detailed spec in place via back and forth with chatgpt + some templates + a validation service in 10 minutes that will consistently get an agent to power for 3+ hours with the end result being 85% test coverage, E2E user story testing, etc so when I come back to the project I'm only doing acceptance testing.

The velocity taking yourself out of the loop with analytic guardrails buys is just insane, I can't overstate it. The clear plan/guardrails are important though, otherwise you end up with a pile of slop that doesn't work and is unmaintainable.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#13

Post by CuriouslyC » Sat, Sep 06, 2025, 2:34 PM UTC

gravypod wrote: post #11

jay-baleine wrote: post #7

Earlier quoted context omitted.

What tends to get overlooked is the actual development speeds these projects achieve. 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. The "more work" claim doe…

> 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…

Claude Code (and claude in general, which was 99% used here) likes regexes for this sort of thing. You have to tell it to use tree sitter, or it'll make a brittle solution by default.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#14

Post by CuriouslyC » Sat, Sep 06, 2025, 2:48 PM UTC

mehdibl wrote: post #9

The most important you need always to do: 1. Plan, review the plan. 2. Review the code during changes before even it finish and fix ASAP you see drift. 3. Then again review 4. Add tests & use all quality tools don't rely 100% on LLM. 5. Don't trust LLM reviews for own produced code as it's very biased. This is basic steps that you do as you like. Avoid FULL AUTOMATED AGENT pipeline where you review the code only at t…

LLMs can review their own code, but you must have a fresh context (so they don't know they wrote it) and you need to instruct them to be very strict. Also, some models are better at code review than others, Gemini/GPT5 are very good at it as long as you give them sufficient codebase context, Claude is not so great here.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#15

Post by CuriouslyC » Sat, Sep 06, 2025, 2:51 PM UTC

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.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#16

Post by perrygeo » Sat, Sep 06, 2025, 2:54 PM UTC

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.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#17

Post by jay-baleine » Sat, Sep 06, 2025, 3:00 PM UTC

gravypod wrote: post #11

jay-baleine wrote: post #7

Earlier quoted context omitted.

What tends to get overlooked is the actual development speeds these projects achieve. 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. The "more work" claim doe…

> 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 converting Python to Rust. When files exceed 300KB, the system delegates transpilation to the Rust binary instead of using Python regex processing.

4. HTTP API: Yes - provides endpoints for transpilation, symbol mapping queries, and engine info to enable IDE integration.

The technical decision to use string replacement over AST manipulation came down to measured performance differences.

The benchmarks show 3,000,000+ chars/sec throughput on extreme stress tests and 1,200,000+ chars/sec on typical workloads. Where AST parsing, transformation, and regeneration introduces overhead that makes real-time symbol conversion impractical for large codebases.

The string replacement preserves exact formatting, comments, and whitespace while maintaining compatibility with any Python syntax. Including future language features that AST parsers might not support yet. Each symbol maps directly to its Python equivalent without intermediate representations that can introduce transformation errors.

The cache system includes integrity validation to detect corrupted cache entries and automatic cleanup of temporary files. Cache invalidation occurs when source files change, preventing stale transpilation results. Batch write operations with atomic file replacement ensure cache consistency under concurrent access.

The runtime serves cognitive improvements for domain-specific development. Mathematical algorithms become more readable when written with actual mathematical notation rather than verbose keywords. It can help in game development, where certain functions can benefit from different naming (eg.: def → skill, def → special, def → equipment).

The gradual adoption path matters for production environments. Teams can introduce custom syntax incrementally without rewriting existing codebases since the transpiled output remains standard Python. The multi-layer caching system ensures that symbol conversion overhead doesn't impact execution performance.

Domain-specific languages for mathematics, finance, education, or any field where visual clarity improves comprehension. The system maintains full Python compatibility while enabling cognitive improvements through customizable syntax.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#18

Post by grork » Sat, Sep 06, 2025, 3:57 PM UTC

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 about this for months, and still don’t know what to make of it.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#19

Post by visarga » Sat, Sep 06, 2025, 4:01 PM UTC

jay-baleine wrote: post #7

sublinear wrote: post #2

This may produce some successes, but it's so much more work than just writing the code yourself that it's pointless. This structured way of working with generative AI is so strict that there is no scaling it up either. It feels like years since this was established to be a waste of time. If the goal is to start writing code not knowing much, it may be a good way to learn how and establish a similar discipline within…

What tends to get overlooked is the actual development speeds these projects achieve. 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. The "more work" claim doe…

> The perceived 'strictness' provides flexibility within proven constraints. Developers retain complete freedom in implementation approaches, but the constraints prevent common pitfalls like monolithic files or tangled dependencies - like guardrails that keep you on the road.

I agree, the only way to use AI is to constrain it, to provide a safe space where it can bang against the walls to iterate towards the solution. I use documentation, plans and tests as constraint system.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#20

Post by j45 » Sat, Sep 06, 2025, 4:03 PM UTC

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.

Lol, Empathy and communication skills are important to develop after all.