FWIW I'd think the westernized version would then "retaliate" and favor western over "eastern" users.

That's NOT really creating trust...

That's essential as you should really "own" the solution you sell and take money for, as you're responsible for what it does on your customers' hardware.

- more bugs becoming visible that were hidden within the software we use daily

- more bugs (in absolute terms) as more people create more software in a very short amount of time (regardless of their professional training)

- less bugs in existing software as the developers and dev orgs of existing projects is capable of automating bug hunting, test case creation, ... in essence: They get a multiplying effect out of AI regarding their capabilities.

In short: Actual developers with actual experience (the more, the merrier) can do better work while the barrier to enter "the market" for untrained individuals is a lot lower resulting in a huge amount of new software whose "success" is to be determined.

Writing code is not the bottleneck anymore, making decisions is. Making the right decisions needs context and thinking. A coffee break might actually help productivity. Driving a Ferrari full speed in a crowded city - only because you can - doesn't make the outcome better.

Comments URL: https://news.ycombinator.com/item?id=48635995

Points: 1

# Comments: 0

We need to learn to be more conscious about the impact our way of doing things has.

Suffice to say they need to get their own search index fully filled and stop using Bing (or whatever US-based) data. It's a process...

Kudos! The site rocks as well! I also have an api-first SaaS (see https://thelawin.dev), but it unfortunately needs a bit more explanation.

Best, Steviee

- my very own (probably flawed) workflow sometimes changes planned features along the way which tends to get source code and feature descriptions out of sync - I wanted Claude Code (or Codex) to be faster when accessing the planned tasks - have everything checked out that's needed for work to be able to work offline (sometimes happens on a boat etc.)

So, in short:

Issues stored as YAML-frontmatter Markdown files in .issues/, version-controlled alongside your code. Zero infrastructure: one Go binary, no server, no database, no accounts.

Built for two workflows: - Human: issues list, issues show, issues board (interactive TUI) - Agent: issues next → issues claim → issues done . Auto-generates .agent.md context for Claude Code and other agents.

Relations (blocks, depends-on, related-to, duplicates) are bidirectionally synced. Every change auto-git add-ed. Issues travel with branches, git bisect shows state at any commit.

go install github.com/steviee/git-issues@latest

What do you think?

Comments URL: https://news.ycombinator.com/item?id=47973644

Points: 1

# Comments: 4

I created a little Github Issues replacement for myself that puts the issues within the repo so that the work and the todos stay in sync. https://github.com/steviee/git-issues

And I bet there's numerous other projects like that.

Hope you get your submarine, man! ;)

I built Thelawin because EU e-invoicing is one of those boring problems that gets surprisingly deep once you ship it.

The basic idea is simple: send invoice JSON, get an EU e-invoice back.

It currently supports ZUGFeRD, Factur-X, XRechnung, UBL, CII, Peppol, FatturaPA and plain PDF output. For PDF-based formats it returns PDF/A-3 with embedded XML. There is also a validation endpoint, so you can check the JSON before generating the invoice.

The API is stateless by design. Invoice data is processed, returned, and not stored. Usage logs do not contain invoice contents.

I also added an MCP endpoint. The goal is that an agent can pass sender, buyer and invoice-line data to a schema-bound tool instead of trying to produce invoice XML itself.

There is a public sandbox flow here: https://thelawin.dev/ai

I would be interested in feedback from people who have dealt with e-invoicing, ERP integrations, accounting software, Peppol, or PDF/A-3 generation. The hard part is not making a PDF. The hard part is avoiding all the small format mistakes that only show up when a real customer tries to submit the invoice somewhere.

Comments URL: https://news.ycombinator.com/item?id=47909874

Points: 1

# Comments: 0

I built git-issues to be used as a replacement for my Github Issues based workflow where I direct my coding agent to put up tasks and context besides the README.md.

This works as long as the Github Issues and what you're actually developing is in sync. However you can't just branch out, change the plan and explore something that easily with non-versioned Tasks. Also you can't revert to a certain composition of tasks just like that.

All this changes when your tasks are part of the repo and commit-history.

It's all self-contained.

Hope you find it useful.

Best, Steviee

Comments URL: https://news.ycombinator.com/item?id=47456672

Points: 2

# Comments: 0

DopaLoop is an iOS habit tracker that starts with goals ("better sleep", "less overwhelm") and lets you attach habits to them. Miss a day: nothing resets. The goal stays visible as an anchor or Northstar. The idea is that patterns over time matter more than daily streaks.

Tech: SwiftUI + SwiftData, with Foundation Framework and CoreML, fully local, no backend, no account. Privacy wasn't just a marketing decision, really. I just didn't want anyone to fear for their data, including myself or my kids. Everything stays on-device.

14-day free trial to get some momentum and gain insights from the analytics. No ads, no data collection.

Source isn't public, but happy to answer questions about the SwiftUI/SwiftData architecture, the HealthKit integration, or the ADHD-specific design decisions.

dopaloop.app (https://dopaloop.app/)

Best, Steviee

Comments URL: https://news.ycombinator.com/item?id=47314769

Points: 5

# Comments: 0