HN user

kevinherron

1,150 karma

I am a software developer in the industrial automation world...

kevinherron@gmail.com https://github.com/kevinherron https://github.com/digitalpetri

Posts0
Comments494
View on HN
No posts found.

Codex is great, both the CLI and Codex.app.

I regularly use both Claude Code and Codex; work pays for Claude, my personal sub is for Codex.

Opus 4.7 and GPT 5.5 seem equally competent. They have distinct “feels” when interacting, and perhaps each have strengths and weaknesses, but I don’t really see one as better than the other.

Complete opposite in my experience. AI does best in a well established code base where it can use existing patterns as context. When you let it loose on a greenfield project and don't carefully and explicitly keep it in check you get back crap.

We write mostly Java, some Kotlin, targeting the JVM.

Most commonly our software runs on premises on server-class hardware (or what passes for server-class depending on the industry...), sometimes hosted in the cloud, sometimes on "edge" hardware (think Raspberry Pi class power/spec wise).

One component of the software actually is a web frontend (and a Jetty backend) to go with it, but it's not your typical "web-app" and it's not SaaS. But there's much more to it than that.

The problem is you still think that the perfect prompt or AGENTS.md or whatever is going to get you a one-shotted (or close) feature in return. There isn't (yet) a model or orchestration framework that is going to take a large feature from start to finish for you.

The reality is that LLMs/agents are just a new way to write code. You still need to understand, more-or-less, how this feature is going to actually work, and how it needs to be implemented, from start to finish.

The difference is that you don't write the code, you tell the LLM to write the code. Once you've figured out the right "chunk size" an LLM can handle it's faster than doing it yourself.

I've found it's actually a little _harder_ in green field projects because the LLM doesn't have guard rails and examples and existing patterns to follow.

One model/configuration will never work because developers are awful, picky customers.

You’ll lose 90,000 of your 100,000 with one or more little nitpicks.

Probably 50% right off the bat because you chose a keyboard with or without a numpad.

Another huge chunk because you chose the wrong screen (Retina resolution? Low resolution? Refresh rate?)

Too bad, because I want this. Or at least the version of it I have in my head :)

I flew to NYC and back last week and never experienced anything like this with mine shrug

The 3s have been an improvement on the 2s for me, especially in fit and feel in ear.

We use it for (non-Spring) backend development. It's lovely and always my first choice over Java.

I like to avoid mixing Java/Kotlin within the same module when I can, but it still works, and parts of our codebase are mixed this way. (by module I mean e.g. the same Maven or Gradle module, i.e. try to avoid a situation where you have a `src/main/java` and `src/main/kotlin` next to each other)

in a move that exchanges Windows and Office 365 for Linux and LibreOffice.

It'll migrate about half of the Ministry of Digital Affairs away from Windows this summer

I’ve been using Wayland since it became the default in Fedora. These days it seems to be working great. I’m especially happy with how well KDE seems to work on Wayland now.

I'm primarily a macOS and Linux user, but I do have a 2nd work laptop and a VM I use for Windows, both of which I upgraded to Windows 11 2-3? years ago.

There's never been an issue. It's a better experience than W10 was. I don't really understand why everybody is upset.

I don't play video games so maybe that's part of it?

Jesus nut 3 years ago

Hmm, for anchors, or for that first piece (or two) that would keep you off the deck or from falling on the belay anchor?