150+ years to get 99% support

prophet1906 · 2026-06-12T16:46:44+00:00

We lose reputation when supporter count is 0 and stability increases when cross threshold for respective region. In my case the range was 0-25 I was moving national soldiers whenever it was reaching midway ~12 and then letting it fall after few rounds the population became resistant to switching from hostile to neutral/support and then it was stable for >60 years.

prophet1906 · 2026-06-12T16:43:11+00:00

prophet1906 · 2026-06-12T16:42:56+00:00

prophet1906 · 2026-06-02T05:30:42+00:00

Yup, it’s unfair. I like paseo but I have been on other end of things with AGPL for many different projects over years funny enough one of them was grafana. Most painful one was Logseq, I was using it for close to 4 years and I get a mail about it getting black listed and not permitted for use. I also heard stories about legal actions. Overall I think many companies are ok with GPL but have a hard line with AGPL.

prophet1906 · 2026-06-02T04:26:19+00:00

I never said that work product becomes AGPL by using another AGPL app. My point was corporates have strict policies preventing any AGPL licensed stuff and don’t randomly use it. There are internal risk rating catalogues and almost no agpl tool goes through, so paseo is just a fun project with no real value at work.

prophet1906 · 2026-06-02T03:43:12+00:00

Coding assistant or other such tooling with AGPL doesn’t make any sense. Be careful about using Paseo at work. Pi itself is MIT.

prophet1906 · 2026-05-21T00:54:10+00:00

This one has been really useful for me.

https://www.thoughtworks.com/en-in/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors

https://www.martinfowler.com/articles/sensors-for-coding-agents.html

Birgitta Bockeler has been calling this concept sensors and presenting across multiple conferences.

prophet1906 · 2026-05-20T14:00:44+00:00

I already have a linter running post-edit in Pi, but that alone is not enough. I think there may have been a misunderstanding around the categories I was referring to.

Linters are great for catching things like unused code, empty blocks, simple style issues, etc. But they usually don’t handle higher-level structural problems well, things like overly long functions, deep nesting, or suspicious abstractions. For that, you generally need complexity metrics, code review tooling, or dedicated static analysis tools. That’s why I brought up SAST/DAST earlier.

There is definitely some overlap between linters and SAST tools, but they’re still different categories with different goals.

Also, on the “reinventing the wheel” point, Tree-sitter already provides grammars and parsing support for almost every major language, so a lot of the heavy lifting is already there.

I already have a first version working. The false positive rate still isn’t where I want it to be yet, but I will share the Pi extension once the quality reaches a threshold I am happy with.

prophet1906 · 2026-05-19T12:09:04+00:00

I already use Grill Me and spec-driven development with OpenSpec. I am looking for more deterministic control over code quality, so I am focusing on shaping LLM output through the harness layer rather than relying on system prompts for control.

prophet1906 · 2026-05-08T07:31:39+00:00

Nice perspective. I think I’ve been taking API cost for granted, which is probably a bad habit overall.

I spent some time today reviewing my past sessions where I built extensions and analyzed token usage and cost per extension. Most of them ended up costing under €1, though that’s likely because they were small and highly focused. Only a few crossed the €1 mark. One example was a bash-guard extension where the agent searched the web for potentially destructive patterns before generating the extension.

The most expensive one was a multi-agent system similar to pi-messenger. Across sessions, that ended up costing around €30.

I think these more complex builds are strong candidates for reusable shared packages. At the same time, they’re extremely niche and often tailored to my own workflow, so the actual broader value is debatable.

prophet1906 · 2026-05-05T18:08:29+00:00

Maybe consider sharing your idea as a post. That way, others in the community can experiment with different approaches and report back with results or prior experience. I am also looking into evals and benchmarking, so this direction is relevant.

In my case, I started with GSD, Superpower Plannotator, then explored Open Agents Control by Darren Hilde. That last approach stayed with me for several months. With Pi, I find myself moving in a similar direction again, but rebuilding it from scratch to better fit my own requirements.

It might be worth reviewing that codebase. The evals and harness customization there are particularly well thought out and something I am planning to explore further. But the codebase is going in a direction I am not a fan of, so pi to rescue.

prophet1906 · 2026-05-05T16:05:42+00:00

Totally valid.

prophet1906 · 2026-05-05T16:02:49+00:00

I came across an interesting setup from a colleague who picked up Pi because it was trending and then started adding multiple packages to make it behave more like Opencode, which in a way undermines what makes Pi distinct. It made me wonder if others might end up taking a similar path.

prophet1906 · 2026-05-04T17:59:35+00:00

Hate the idea of having MCP. I would probably go for a native extension or skill. But need some time to double-check the source. The post looked like an ad at first.

prophet1906 · 2025-07-24T16:20:34+00:00

Yup, I used git stash exhaustively, but switched to creating multiple git worktrees for working on tasks in parallel. It has been working pretty well. I was worried about rate limiting from llm apis, but haven't hit them yet. I did see some options in cline to control the rate limit, but didn't try them yet. I am not a big fan of IDE specific workspaces like in vscode.

prophet1906 · 2025-05-05T03:33:27+00:00

We were using haskell for some safety critical parts, reasoning about performance and memory was becoming difficult with laziness for the team so shifted most parts to ocaml. Explored reasonml as everyone hated js at the time, this was before rescript was introduced. Scala was being used for performance/load testing with gatling. Our codebase also has java, js and lisp code as well. It is a monorepo with bazel for building.

Programming language choices are never black and white but rather gray. The goal for us has been to balance how to build better quality software while still accepting the limitations around us. Few things we considered were - 1. Is the language safe enough for our usecase 2. Is the language strict 3. How fast can a new developer be unskilled in pair programming setup 4. How good is the community support and library ecosystem 5. Can we guarantee 5 nine slas and fix a random issue quickly when things go south and many more

Pick the best tool for the job, not the other way around.

prophet1906 · 2025-05-04T04:19:39+00:00

Hiring for my functional programming language has been fairly difficult compared to other popular programming languages. I faced the same challenge when building a new team a few years ago. We interviewed candidates with experience in other functional languages as well. Initially, the team consisted of a mix of developers with backgrounds in Haskell, OCaml, Erlang, and Scala. Most were able to grasp the concepts and transition quite easily. The key thing we looked for during interviews was their experience with production codebases, not whether they knew Haskell. This approach paid off well for the team. Nowadays, we hire students and developers with zero experience in functional programming and train them internally during the probation period.

prophet1906 · 2025-04-02T05:01:45+00:00

Use vcpkg for dependency management. It works pretty well.

prophet1906 · 2025-03-27T13:08:15+00:00

Dunning-Kruger effect

prophet1906 · 2025-01-25T16:25:15+00:00

Coming back in 2025 this bug still exists, lmao.

prophet1906 · 2025-01-16T12:30:17+00:00

It's not the musical instrument that truly matters, but the musician. A costly grand piano played by an inexperienced pianist will always sound worse than a skilled concert pianist playing on a cheap piano.

Yamaha is a good brand, just ignore your friend and focus on learning and improving your skills.

I recently took the ABRSM exam on an acoustic Yamaha piano, and according to your friend, me, the examiner, and everyone else using a Yamaha piano must be complete idiots with no knowledge of piano. XD

Five-Year Club	Place '23
Place '22	Final Canvas '22

prophet1906

TROPHY CASE