[leonidasrup]

It depends on the kind of software you are programming.

If you are programming regular commercial software (office applications, web apps, games) with customers tolerating occasional bug and lot of pressure deliver fast, you can gain lot from Claude. Facebook motto: Move fast and break things

If you are programming software for industrial applications, critical software, most of the time you spend is not on writing software but writing tests, documenting, doing multiple rounds of reviews and for really critical applications doing formal verification. In this case AI can be also counterproductive, because if you absolutely have to understand every single line of code, manual coding helps to understand the code.

Example of cutting costs in programming of critical software

https://www.industryweek.com/supply-chain/article/22027840/b...

[K0balt]

That’s most of my work(embedded sensor and control networks) and I’m sure that informs my methodology. I honestly don’t know much about how AI can inform standards SAAS but I have seen what happens when you just turn it loose, and in my experience it hasn’t been pretty; it works, but then when you need to change something it all crumbles like a badly engineered sandcastle.

OTOH for single purpose pipelines and simple tools. Claude can oneshot small miracles in 5 minutes that would take me 2 hours to build.

An example is the local agent framework that I had Claude spinup to do JTAG testing. I used to spend hours running tests over JTAG, now I have a local model run tests that Claude and I specify in the test catalog and it just runs them every time we add features. It took Claude minimal guidance and about 3 hours to build that tool along with a complete RAG system for document ingestion and datasheet comprehension, running locally on my laptop (I know it has a fan now lol) that only reaches out to the cloud when it runs into difficult problems. I don’t care if that is a bit of a mess, as long as it works, and it seems to , so far so good.

The testing is where Claude is basically magic, but it’s because we specify everything before we build and change the specs when we change the IRL code that it works. English is code, too, if you build structured documentation… and the docs keep the code accountable if you track the coherence.

[K0balt]

Something maybe worth thinking about.

If you are relying on understanding every single line of code, then maybe you should examine your modularity and testing norms. I don’t know about you, but the next day, I can’t realistically claim to actively hold an understanding of every line of code I wrote the day before. But AI can review 10Kloc and hold it in context with flawless retrieval. I cannot do that.

If you have the right structural framework and don’t approach it as a crutch but rather an amplifier, you can actually improve code quality and documentation while multiplying productivity, and you also don’t get cognitive atrophy out of the deal.

Also, previously unrealistic testing jigs are now trivial to implement, so I can test my code way beyond the point where I would have shipped it before.

AI , like people, makes mistakes. But using AI enables you to pivot to building the infrastructure that assures that no mistakes can escape the lab. That becomes your entire focus, instead of being a burdensome and usually neglected operational overhead.

It’s definitely easy, even tempting, to “hold it wrong” though.