Recent submissions

Comment · 7 hours ago
> With gpt-6.1-sol, my 5-hour limit runs out after just a few requests. If I ask it to change a couple of lines in a readme file, that uses up 10% of the limit

raises an eyebrow .. methinks he exaggerates. I don't think my €20 business plan gets more than the plus plan.

A minor README change with basic verification steps is cheap, or you have totally overdone your AGENTS.md / skills / other steering and have it running around in circles.

In general, if the AI needs to dig through a mammoth codebase to make a simple change, it's likely a codebase / design problem.

If you are making a cross-cutting change that needs that, then you plan up front, then divide & conquer.

Comment · 10 days ago
We could have crossed paths back in the day. Those 25c unlimited local calls felt like such a steal.
Comment · 16 days ago
That would be a Beleidigung... unless you can prove it, and you might have to.

You can criticise Merz's hairstyle, his politics, and his small hands all you like though.

Comment · 8 months ago
It would be exhausting, if it were always necessary. If you spend the time up-front to properly define goals and requirements in a machine+LLM verifiable way, then the agents can manage it in isolation or with minimal oversight, and present a working result that meets those criteria.

BUT: How many people do you know who can achieve sufficient clarity up front? It is a skill (or set of skills) that needs developing. It can also mean the difference between spending $20 in tokens versus $2000, and/or throwing away the result and starting from scratch again (you don't really want to touch an AI generated codebase with fundamental design flaws if you value your time and sanity)

In the meantime, deliberate checkpoints for human review are still a good idea.

My theory: behind every "10x AI coder" is a long trail of expensive failures that never made the light of day, but which they are learning from. The early adopters will therefore have a competitive advantage.

Comment · 8 months ago
There are many security and business risks in developing and releasing software (eg. supply chain attacks, misconfigurations & security-relevant bugs), and many ways to manage them. For companies, this is just another risk to be managed.
Comment · 9 months ago
Indeed. This is very much the way I use it at work. Present an idea of a design, iterate on it, then make a task/todo list and work through the changes piecemeal, reviewing and committing as I go. I find pair design/discussion practical here too. I expect to see smaller teams working like this in the future.

For small personal projects, it's more vibey.. eg. Home automation native UIs & services for Mac & Windows, which I wouldn't otherwise start.. more itches that can be scratched in my limited time.

Comment · 9 months ago
Why learn to play the drums, when there are drum machines? Or play any music, when there are MP3s? Or cook, when there's microwave dinners?

If you can't answer the above, you might want to have a chat with a psychologist. We can and do create meaning in our own lives.

Programming will change, but I won't miss creating the same boilerplate again and again. I expect to focus more on translating the business & technical requirements to decent quality results. I expect good interfaces and separation of concerns will be even more important, as whole modules might be rewritten from scratch rather than being modified, changing the way we think about maintainable code.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton