1,786 karma · joined June 23, 2007
Twitter: http://twitter.com/pramodbiligiri
LinkedIn: http://www.linkedin.com/pub/pramod-biligiri/23/65a/b97
Email: pramodbiligiri AT (Google’s email service).com
Their main site (https://tornadovps.com) has been down for hours, and probably all sites hosted on it: https://www.isitdownrightnow.com/tornadovps.com.html
I built one such tool for myself: https://www.shipsmooth.net. You can use it to spec/plan out a piece of work, and then easily keep updating the spec/plan as you churn through its implementation. The tool assumes that you will pretty much end up changing the spec/plan during implementation, based on how it's going. In general, I don't see how it's possible to one-shot high quality code for custom use cases.
[1] Going by the definition of flow state here: https://en.wikipedia.org/wiki/Flow_(psychology): "fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting transformation in one's sense of time."
Perhaps the more interesting bit is that it's in Java (not Typescript or Rust)! Java 25 is pretty neat. Bonus: getting to know how to distribute a self-contained Java program using jlink and the likes: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli...
In their podcast interview, they mention that it's an Electron app that users download, and so they periodically create a new build. See section "Autonomous Merging Flow" here: https://www.latent.space/p/harness-eng
It could be that because coding was seen as expensive and a bottleneck, much effort (both upstream and downstream) had been going into making sure its input is correct and the output need not be discarded. If coding is seen as a quick and cheap step, its output could stand to be thrown away and therefore the same amount of oversight may not be needed upstream?
May not work for apps that want to launch their own threads and processes. But for almost everything else, I prefer function calls to launching processes, managing their lifecycle, communicating via stdout etc. If I wanted to do that, I’d be writing Bash ;)
Did the same with this Cloudflare one the other day: https://news.ycombinator.com/item?id=48276152
I'm building a skill + CLI tool along those lines (for solo devs not corporates). Here is what my "lifecycle" type skill looks like right now: https://github.com/bitkentech/shipsmooth/blob/releases/dist/... (warning, heavily work in progress). You can see a demo here: https://shipsmooth.net/
I was not happy with the default code quality generated by Claude Code. So I've been adding some skill-file rules to address that, and so far happy with the results: https://github.com/bitkentech/shipsmooth/tree/main/skills/ex.... There was a similar one on HN yesterday called opencodereview: https://news.ycombinator.com/item?id=48406358
There are many such workflows out there! Matt Pocock gave a good talk about how he approaches it: https://www.youtube.com/watch?v=-QFHIoCo-Ko
I've noticed that LLMs tend to generate multiple testcases in one shot (which is not how humans usually go about TDD), and also they don't start with Integration Tests, unless instructed to do so.
The original rules files (in Chinese): https://github.com/alibaba/open-code-review/tree/main/intern...
Some of them are about general coding guidelines and code quality, not necessarily vetting your current PR against specs! There's AbsolutelySkilled with clean-code and clean-architecture. Linking to older version of repo because they seem to be no longer on trunk: https://github.com/AbsolutelySkilled/AbsolutelySkilled/tree/...
I've been creating some rules to help with my Java coding: https://github.com/bitkentech/shipsmooth/tree/main/skills/ex.... These are assembled into a SKILL file when this skill file template is built: https://github.com/bitkentech/shipsmooth/blob/main/skills/ex...
Like with "SKILL" files in general, it's got to do with Prompt Engineering: https://en.wikipedia.org/wiki/Prompt_engineering#Rationale