cwsx

It needed to happen 10+ years ago - unfortunately we've missed the window to unionize

Even when it's not DNS it's probably still DNS (you just haven't found the real issue yet)

What's the appeal of collecting high priced watches? Is it kind of like art collections, where its a decent store of value while maintaining a collection of something you are personally interested in? Or is it more for "love of the game"?

Not saying its not a cool thing to collect, well made watches are a very cool piece of engineering, I'm just curious if there's any "special" appeal outside of "i like this thing and have the money to enjoy it" :)

Suddenly, LoC returned

My main issue was the loss of _tactile_ F keys - hard to touch type when you're finger mashing a narrow touch screen

I had to learn Prolog for a university paper and I have to agree; out of the dozen-ish languages I've had to learn, something just didn't "click" with Prolog.

No real value is this comment, I'm just happy to share a moment over the brain-fuck that is Prolog (ironically Brainfuck made a whole lot more sense).

I tell people to treat LLM's like a toddler (albeit a very capable toddler).

Do kids learn well when you only tell them what NOT to do? Of course not! You should be explaining how to do things correctly, and most importantly the WHY, as well as providing examples of both the "correct" and "incorrect" ways (also explaining why an example is incorrect).

I also have to point out... "NEVER run destructive/irreversible *git* commands". So technically it DID follow the rules.

Fixed link for you (you had an extra W): https://clawdrop.org

Obligatory xkcd

https://xkcd.com/538/

BAND-AID is another one

This is so fucking cool - took me a bit to figure out how the rendering/movement worked but fun after that.

What is the end-goal of this... would it be data exfiltration vs ransomware.

The end-goal is to gain complete access to the system - the outcome (data theft or ransomware) is customers choice

Thanks so much for this!

I've had an ROG Zeph collecting dust for a couple years now, specifically for the reasons you described, which I now have a good reason to dig out and poke around in. Got my weekend sorted :)

it's almost like the administration doesn't care for accurate data

ChatGPT does well for chemistry questions just btw

I wrote a comment in a similar thread a few weeks ago describing my LLM-coding experience - here's a copy+paste (so any quote replies will be out of context / not actually replying to your comment):

    I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.

    > I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.

    There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):

    - _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_

    - your entire workflow NEEDS to be centered around LLM-development (or even model-specific):

      - use MCPs wherever possible and make sure they're specifically configured for your project

      - don't write "human" documentation; use rule + reusable prompt files

      - you MUST do this in a *very* granular but specialized way; keep rules/prompts very small (like you would when creating tickets)

      - make sure rules are conditionally applied (using globs); do not auto include anything except your "system rules"

      - use the LLM to generate said prompts and rules; this forces consistency across prompts, very important

      - follow a typical agile workflow (creating epics, tickets, backlogs etc)

      - TESTS TESTS AND MORE TESTS; add automated tools (like linters) EVERYWHERE you can

      - keep your code VERY modular so the LLM can keep a focused context, rules should provide all key context (like the broader architecture); the goal is for your LLM to only need to read or interact with files related to the strict 'current task' scope

      - iterating on code is almost always more difficult than writing it from scratch: provided your code is well architected, no single rewrite should be larger than a regular ticket (if the ticket is too large then it needs to be split up)

    This is off the top of my head so it's pretty broad/messy but I can expand on my points.

    LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.

    The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in.

I'm not really that invested in this topic but my assumption on "why flag this?" is because you're making some wild claims that have no factual basis to go off - your only "references" are random pastebins.

Right now your comment reads like something off a conspiracy forum and has nothing to back it up - which is not something that warrants discussion (on HN).

I'd even argue the general idea of capitalism is virtuous by default.

I wouldn't, in my opinion:

Capitalism incentivizes selfishness at the detriment of others that are "playing the [capitalism] game" or anti-competitive practices. It also pushes people to hoard resources - think Tragedy of the Commons or anti-competitive practices in general. The incentive is to reduce the amount of resources available to competition while increasing your holdings, allowing you to repeat the loop but with higher chances of success.

Providing something others find useful seems like a lucky side effect that often isn't even true, there's a lot of industries who have no intention of providing something useful (like stock trading, short trading especially). Most companies are trying to reduce costs as much as possible, reducing the usefulness of their product/service to the lowest point that people will still pay for.

But I agree with your other points - just because capitalism breeds selfishness it doesn't mean all parties are going to the extremes.

Third time's the charm!

The most accurate representation of "Chaotic Neutral" - the cheeky bastards love stealing ANYTHING, and when there's nothing to steal they'll start ripping the rubber off your car door seals (or windshield wipers).

They are amazing birds, very deserving of the name "Clown of the Mountains".

Yet we'll still get the undisciplined engineers whining that they have to write a small and isolated unit test.

Oh I wish that were true for my experiences - much more commonly it's a project manager that doesn't understand the value of tests....

One coulld hire a software developer to write such a program. But, in general, software developers can be untrustworthy and prone to stealing ideas for their own selfish purposes.

Ehhhh? Yes there are examples of that, as there are for any arbitrary group of humans you could select, but [anecdotally] I've noticed the opposite... it's not uncommon to find a passionate developer that's only interested in the challenge/problem solving aspect - it's a lot less common for say.. real estate agents.

I don't really get the point you're making beyond "people be greedy sometimes" (which I do agree with, don't get me wrong).

MCPs:

  - `server-sequential-thinking` (MVP)
  - `memory` (2nd MVP, needs custom rules for config)
  - `context7`
  - `filesystem`
  - `fetch`
  - `postgres`
  - `git`
  - `time`

```

# Ticket Management Guidelines

This document outlines the standardized approach to ticket management in the <redacted> project. All team members should follow these guidelines when creating, updating, or completing tickets.

## Ticket Organization

Tickets are organized by status and area in the following structure:

TICKETS/ COMPLETED/ - Finished tickets BACKEND/ - Backend-related tickets FRONTEND/ - Frontend-related tickets IN_PROGRESS/ - Tickets currently being worked on BACKEND/ FRONTEND/ BACKLOG/ - Tickets planned but not yet started BACKEND/ FRONTEND/

## Ticket Status Indicators

All tickets must use consistent status indicators:

- *BACKLOG* - Planned but not yet started - *IN_PROGRESS* - Currently being implemented - *COMPLETED* - Implementation is finished - *ABANDONED* - Work was stopped and will not continue

## Required Ticket Files

Each ticket directory must contain these files:

1. *Main Ticket File* (TICKET_.md): - Problem statement and background - Detailed analysis - Implementation plan - Acceptance criteria

2. *Implementation Plan* (IMPLEMENTATION_PLAN.md): - Detailed breakdown of tasks - Timeline estimates - Success metrics

3. *Implementation Progress* (IMPLEMENTATION_PROGRESS.md): - Status updates - Issues encountered - Decisions made

4. *Design Documentation* (DESIGN_RECOMMENDATIONS.md), when relevant: - Architecture recommendations - Code patterns and examples - Error handling strategies

5. *API Documentation* (API_DOCUMENTATION.md), when applicable: - Interface definitions - Usage examples - Configuration options

## Ticket Workflow Rules

### Creating Tickets

1. Create tickets in the appropriate BACKLOG directory 2. Use standard templates from .templates/ticket_template.md 3. Set status to *Status: BACKLOG* 4. Update the TICKET_INDEX.md file

### Updating Tickets

1. Move tickets to the appropriate status directory when status changes 2. Update the status indicator in the main ticket file 3. Update the "Last Updated" date when making significant changes 4. Document progress in IMPLEMENTATION_PROGRESS.md 5. Check off completed tasks in IMPLEMENTATION_PLAN.md

### Completing Tickets

1. Ensure all acceptance criteria are met 2. Move the ticket to the COMPLETED directory 3. Set status to *Status: COMPLETED* 4. Update the TICKET_INDEX.md file 5. Create a completion summary in the main ticket file

### Abandoning Tickets

1. Document reasons for abandonment 2. Move to COMPLETED/ABANDONED directory 3. Set status to *Status: ABANDONED* 4. Update the TICKET_INDEX.md file

## Ticket Linking

When referencing other tickets, use relative links with appropriate paths:

markdown @TICKET_NAME

Ensure all links are updated when tickets change status.

## Ticket Cleanup and Streamlining

### When to Streamline Tickets

Tickets should be streamlined and cleaned up at major transition points to maintain focus on remaining work:

1. *Major Phase Transitions* - When moving between phases (e.g., from implementation to testing) 2. *Milestone Achievements* - After completing significant portions of work (e.g., 80%+ complete) 3. *Infrastructure Readiness* - When moving from setup/building to operational phases 4. *Team Handoffs* - When different team members will be taking over the work

### What to Streamline

*Replace Historical Implementation Details With:* - Brief completed tasks checklist ( high-level achievements) - Current status summary - Forward-focused remaining work

*Remove or Simplify:* - Detailed session-by-session progress logs - Extensive implementation decision histories - Verbose research findings documentation - Historical status updates and coordination notes

### Why Streamline Tickets

1. *Git History Preservation* - All detailed progress, decisions, and implementation details are preserved in git commits 2. *Clarity for Future Work* - Makes it easier to quickly understand "what needs to be done next" 3. *Team Efficiency* - Anyone picking up the work can immediately see current state and next steps 4. *Maintainability* - Shorter, focused tickets are easier to read, understand, and keep updated

### How to Streamline

1. *Archive Detailed Progress* - Historical implementation details are preserved in git history 2. *Create Completion Summary* - Replace detailed progress with a brief "What's Complete" checklist 3. *Focus on Remaining Work* - Make current and future phases the primary content 4. *Update Status Sections* - Keep status concise and action-oriented 5. *Preserve Essential Context* - Keep architectural decisions, constraints, and key requirements

*Goal*: Transform tickets from "implementation logs" into "actionable work plans" while preserving essential context.

## Maintenance Requirements

1. Keep the TICKET_INDEX.md file up to date 2. Update "Last Updated" dates when making significant changes 3. Ensure all ticket files follow the standardized format 4. Include links between related tickets in both directions

## Complete Documentation

For detailed instructions on working with tickets, refer to:

- @Ticket Workflow Guide - @Ticket Index - @Tickets README

```

The "cardinal rule of agent design" should be that an LLM can have access to at most two of these during one session. To avoid security issues, agents should be designed in a way that ensures this.

Then don't give it your API keys? Surely there's better ways to solve this (like an MCP API gateway)?

[I agree with you]

For greenfield it’s amazing

I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.

I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.

There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):

- _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_

- your entire workflow NEEDS to be centered around LLM-development (or even model-specific):

  - use MCPs wherever possible and make sure they're specifically configured for your project

  - don't write "human" documentation; use rule + reusable prompt files

  - you MUST do this in a *very* granular but specialized way; keep rules/prompts very small (like you would when creating tickets)

  - make sure rules are conditionally applied (using globs); do not auto include anything except your "system rules"

  - use the LLM to generate said prompts and rules; this forces consistency across prompts, very important

  - follow a typical agile workflow (creating epics, tickets, backlogs etc)

  - TESTS TESTS AND MORE TESTS; add automated tools (like linters) EVERYWHERE you can

  - keep your code VERY modular so the LLM can keep a focused context, rules should provide all key context (like the broader architecture); the goal is for your LLM to only need to read or interact with files related to the strict 'current task' scope

  - iterating on code is almost always more difficult than writing it from scratch: provided your code is well architected, no single rewrite should be larger than a regular ticket (if the ticket is too large then it needs to be split up)

LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.

The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in.

I've been using `claude-4-sonnet` for the last few hours - haven't been able to test `opus` yet as it's still overloaded - but I have noticed a massive improvement so far.

I spent most of yesterday working on a tricky refactor (in a large codebase), rotating through `3.7/3.5/gemini/deepseek`, and barely making progress. I want to say I was running into context issues (even with very targeted prompts) but 3.7 loves a good rabbit-hole, so maybe it was that.

I also added a new "ticketing" system (via rules) to help it's task-specific memory, which I didn't really get to test it with 3.7 (before 4.0 came out), so unsure how much of an impact this has.

Using 4.0, the rest of this refactor (est. 4~ hrs w/ 3.7) took `sonnet-4.0` 45 minutes, including updating all of the documentation and tests (which normally with 3.7 requires multiple additional prompts, despite it being outlined in my rules files).

The biggest differences I've noticed:

  - much more accurate/consistent; it actually finishes tasks rather than telling me it's done (and nothing working)

  - less likely to get stuck in a rabbit hole

  - stopped getting stuck when unable to fix something (and trying the same 3 solutions over-and-over)

  - runs for MUCH longer without my intervention

  - when using 3.7:

     - had to prompt once every few minutes, 5 - 10mins MAX if the task was straight forward enough

     - had to cancel the output in 1/4 prompts as it'd get stuck in the same thought-loops

     - needed to restore from a previous checkpoint every few chats/conversations

  - with 4.0:

    - ive had 4 hours of basically one-shotting everything

    - prompts run for 10 mins MIN, and the output actually works

    - is remembering to run tests, fix errors, update docs etc

Is Copilot _enforced_ as the only option for an AI coding agent? Or can devs pick-and-choose whatever tool they prefer

I'm interested in the [vague] ratio of {internallyDevlopedTool} vs alternatives - essentially the "preference" score for internal tools (accounting for the natural bias towards ones own agent for testing/QA/data purposes). Any data, however vague is necessary, would be great.

(and if anybody has similar data for _any_ company developing their own agent, please shout out).

Coding is, and always has been, the easy part of software development

I switched to them a few months ago, I was previously using duckduckgo (and Google before that). As most of you have probably noticed Google search results have seriously dropped in quality the last few years, but especially in 2023. I'm no longer able to get meaningful results for almost any topic, especially if it's technical, the only results are AI generated (?) / obvious SEO spam websites. It takes me multiple different search terms and clicking through multiple results to find anything semi relevant, and even then it's a shallow article maybe summarising what I'm looking for. Unfortunately DDG seems to be going the same way.

Whereas Kagi reminds me of the 'old' google search. The results are meaningful and relevant, not diluted with pages of generic article results. They also offer a lot of great customisation options like being able to block or boost certain sites in results. They have some built in lists for common filler sites. I can't comment on the AI variation but I hear that's progressing well.

I wouldn't call myself a power user of Kagi, but even then I'm getting far better results than other search engines, definitely worth the price per month.

I'm not affiliated with them in any way, just thought I'd share my anecdotal experience.