airbreather

8 months ago I got claude to do a perfect reproduction of the arcade asteroids game on a simple prompt and a once through.

I then got it to do lunar lander, that was also perfect, and very hard to land.

"If you specify every possible detail in a design doc, you’ve essentially written the implementation during the design phase. That would defeat the whole purpose of a design doc."

However if you do this as an executeable specification then the job of core functionality is finished with the specification, with significantly beeter quality, potentially.

This sounds a lot harder than it is - most behaviour is state based and it is possible to define such behaviour with an executeable specification.

In the Functional Safety world this is often your best option.

I wrote my own software package to enable such practices and once used to a slightly different way of thinking it works very well.

There are more than one set of tuning settings, depending whether optimised for start up, steady state, minimum overshoot etc

Pretty easy to tune really - almost never use derivative, increase the proportional until oscillations occur then halve it, add a little integral, not so much it oscillates.

based on multiple personal experiences, and that of friends/acquaintances, I have no doubt it works for reduction of inflammation of the sort you get spraining you ankle.

must be taken with pepper extract to increase bio availability, I buy it ready to go from the supermarket where they keep it with the vitamins and supplements.

just because no one has worked out how, does not mean it is ineffective.

have you tried NULL?

Conflict arises from differing or unmet expectations.

So the easiest way to eliminate a lot of issues is clearly agree and define expectations up front.

There is a reason a whole branch of project management is called Expectation Management.

AI allows anyone with a minimum amount of intelligence and operational expertise to become an "Expert Beginner" (currently).

What can you do with a whole team comprised only of Expert Beginners?

this is fucking awesome

it is fast, there is no fucking gateway fuckaround or any other similar issues, up and going in seconds

straight away I added two skills, that it wrote for itself, read my gmails and attachments, and browse the web, text browser first up, render page and screenshot with OCR for javascript heavy pages\

then I asked it, find the best value ram in my area, second hand as well as new, try gumtree and facebook marketplace, plus anything else relevant, bam - 15 seconds maybe a concise summarised range of options

then on another project, I told it to /study and then used the gmail plugin to access all the relevant gmails and attachments (which included minutes of all the meetings) and it was fully up to date with the project I am working on and ready to go

best agent I have used so far by a country mile, if you don't try it then that is your loss

did I mention it was fast, like 3x to 5x better productivity fast compared to openclaw, at least

one thing it does not do is support the up arrow/down arrow to scroll thru past commands, but you can just tell it, "run that websearch for ram again" etc, i will totally live witht his for all the other positives

I am sort of in the same place, it seems to have lost enough of the magic that I might be better trying to do more with running local LLMs on my 4090.

The thing is running local LLMs will give some kind of reliability and fixed expectations that saves a lot of time - yeah sure Claude might be fantastic one day, but what do I do when the same workload churns out shit the next and I am halfway thru updating and referencing a 500 document set?

Better the devil you know and all that.

Pdf is all about presentation, not about communication.

While the two can be closely aligned, it is not neccesarily the case, if not often misaligned priorities.

Many pdfs are hard to read based on a consistant set of rules, reliance on edge cases and context and conventions.

Similar to aviation s marine safety. Both started with a bunch of prescriptive rules that were added to as various accidents and near misses occured. As you say.

Then, in the last couple of decades there has been a move to performance based standards.

These work by the designers trying to anticipate hazards specific to the design and it's intended duty, and then providing mitigation to reduce the risk down to sn acceptable level.

This has a number of poditive outcomes, but not least is the expenditure on mitigation is directed in the most economic manner.

All this requires a systrmd approach, and when properly applied has been shown to yield superiour results.

Humans don't really work any better, just fail in different ways. This is why certain workflows and practices have emerged.

We are now in the early days of working through a similar process with AI.

They most definately do work for some use cases, but how they are used is important.

Just because you apply human processes and systems to AI based workflows and don't get historically expected results, this is zero basis to claim the sky is falling with use of AI in coding.

As most results in coding by AI are the result of some kind of recursive application of the fundemental concept, irony is abundant.

Definately, I am similar vintage and work in Functional Safety, see my other comment re specification.

Yes definately, I do a lot of OT devops and if you want determinstic results then the best use of AI is to get it to write scripts that solve your problems and that you run outside of AI.

Often, the use of AI is a lazy case of not wanting to spend the time to understand the essence of the problem and solve it directly, often far more efficiently. (Not always, but often).

The ability of getting results that surpass your understanding, and quickly, is seducing, but you invariably end up being capped on the usefullness.

AI generally seems to raise anyone with the basic skills to "expert beginner" in almost any field, but it is then a big struggle to get past this stage, without substantial extra work.

The problem isn't the AI writing the code, it is the specification - I assert much of the described problems could be rectified by improved specification with no hand coding.

Specification of software has been very weak for decades, and little effort has been put towards defining methadologies of specification that are both exhaustive and unambiguous.

It is possible, I know because I work in an exotic niche where being exhaustive and unambiguous isnot optional - Functional Safety. Here you might spend 90% or more of your time planning what and how to code, before writing the first line.

The cost - I have worked on projects where, across the duration of the project, the average production of code was less than two lines a day.

But when a single error could result in the death of 100, or 300, people, then this time worth it.

You can't get this kind of quality when you pivot twice a week, you need to have fairly fixed objectives.

The are ways to get better outcomes that are known, but not widely applied, and they could do with some development to make them accessible. Some has been done, eg Leslie Lamport and TLA+.

But, as you might have been told as a child, don't get upset that you did not get what you wanted when you failed to ask for it properly.

Even if not explicitly looking like a state machine, it will have state based behaviour that could be represented by a state machine.

Almost everything is state based behaviour.

All the whingers about AI - if it is as bad as you say, then you don't have a problem

On the other hand, if it is not, then stop wasting effort arguing against the inevitable and use that effort to get ahead of the curve.

Either way, whinging about it is the least effective use of your skills and time.

I would suggest that the 1000 line switch statement implies a state machine that has suffered from the "state explosion".

This usually results from an inadequate system-subsystem decomposition and/or not considering modes, both of which lead to hierarchal state machines instead of one big flat one.

This aspect of architecture is difficult to teach, it is one of the "black arts" that comes from experience and is difficult to codify.

Just one example why, is that often it might require the synthesis of state machines not directly evident as needed from the functionality, eg to perform a one to many or many to one functionality.

Just wait long enough

As an electrical engineer with more experience than the average age of the readers here, this is a problem that is way, way more complicated than 99.9% of the population have any concept of, to be generous. This is in terms of grid dispatch and stability.

But we can short circuit that and consider in terms of distributed generation (mostly solar) and storage (batteries), see further down.

But the group website has no real information about real people involved, it's best information is some links to some papers that are not even clear if any members of the group were involved in. There is a photo, but I couldn't see that anyone was named.

Maybe in my 3 minute look I missed something, but it rapidly became fairly obvious that is about all the idea and website seemed to warrant.

It is possible that one person created the website as it totally comes across as "havea big idea and try and cast a big shadow and see if someone will bring some more sunlight".

If I am wrong, then they really need to do a better job of their website, otherwise it looks like an attempt bootstrap on a thought bubble, at best.

Some background:

I live where we have the most isolated grid interconnect system in the world (and it is not Texas) and in this system generation is about 50% of the cost and transmission is the other 50%, so the incentive to optimise the transmission network is probably higher than anywhere else in the world.

The idea proposed sounds attractive, but would have been even more so when there was a far greater abundance of base load generation that could only cycle at relatively slow rates compared to the change in demand rates, but now, as generation becomes increasingly more distributedthe nature of the problems change a little (the duck curve, for example).

Analogs to this concept exist, eg water infrastructure where in order to not have to build expensive fatter pipes for water to serve increasing populations, local water towers are built that pump up at night during low demand and draw down during peaks. There are distinct available economies there, but the round trip energy efficiency is also potentially very high.

I am not sure that economically any similar equivelent for electricity could be implmenented, especially when compared to the cost of solar generation and the recent plunge in battery costs, it now is far more likely that at a household level it would be cheaper to get some solar panels and a decent sized battery and be done with it, at city block level probably even more economic as there is effectively no transmission, it is all distribution, so near 50% could be saved already on end use costs.

I just don't see it.

As always has been, but for most of two boom times throught he industry was forgotten, is that specification is everything.

If you adequately specify what you want, then LLM's today are perfectly capable to produce code of a quality exceeding most humans.

But what has been going on is that many of the details of architecture and code have been implied as "good practice" or "experience" because it is time consuming to write a good specification, partly because you need to first work out exactly what you want.

I am 60 in October, I have a couple of PyQt projects that were desktop apps, specialised tools I use for Electrical Engineering and Control/Safety Systems design and build.

So I decided that I wanted web apps, something that is probably beyond me in any reasonable time, if at all, if I was to code myself by hand.

For my coding AI "stack" I am now running OpenClaw sitting on top of Claude Code, I find the OpenClaw can prompt Claude Code better and keep it running for me without it stopping for stupid questions. Plus I have connected OpenClaw to my Whatsapp so I can ask how it is going or give instructions to the OpenClaw while not at the keyboard.

One app was a little complex with 35,000 loc, plus libraries etc. I reckon I had spent maybe 2500 hours on it over some years, but a significant part of that was developing the algorithm/workflow that it implemented - I only knew roughly what I wanted when I started, writing several to throw away at the beginning.

AI converted it to a webapp overnight, with a two sentance prompt, without intervention of any kind.

It took me another 15 minutes and a couple of small changes, mostly dependancies issues, and I had a working version of the same app that was literally 95%+ of the original, in terms of funcitonality and use.

I have a bunch of ideas for things I want to make that I probably never would have been able to otherwise.

I am just totally unable to fathom people that just make a blanket proclamation that AI is good for nothing. I can accept that it is not good for everything, it may cause some social disruption and the energy use is questionable, but improving, but not useful? Wake up.

I am in Australia and got a US General class license because for some time the Australian licensing was in total chaos while changing over to new arrangements.

I did it online thru the New York Radio Club (?).

I did Novice then General in about 30 minutes. I studied for maybe 6 hours immediately prior.

I grew up from age 5 in my Dads ham shack in NZ - every single thing he had made, transmitters, receivers, antennas, the feed wire, oscilloscope, signal gens, grid dip oscillator etc with many parts salvaged. In NZ in those days that is how most people did it, at least partially.

I also have an Electrical Engineering degree.

So sort of had a bit of background working knowledge, which meant I wasn't starting from scratch.

KK7RBX

I have already achieved the same thing getting my openclaw to instruct and manage claude code.

It also seems to provide a substantially better experience of claude code, picking up when it is looping and breaking it and restarting, plus handling all the stupid questions claude code asks, hanging on. (Even when started with dangerously I cant be rid of them).

All in all they seem to be a match made in heaven and I strongly suggest you try this.

Because the development process requires Functional Safety and most regular programmers will struggle with the glacial progress that occurs under such regimes.

While IEC 61508 is the parent of all Functional Safety, medical devices are a little divorced form 61508 and have their own primary standard IEC 60601.

Some good explanation occurs here https://blog.johner-institute.com/systems-engineering/functi....

But this is the sort of engineering where you know everything about what your functionality will be, and what code and what type of code will be used to achieve it, well before you even think about starting to code.

The testing requirements can include things like testing every possible combination of inputs, for every possible combination of states (often just not practical, but there are some techniques to say, we will ignore these combinations etc). Every part of the final code shall be traceable back to a requirement so on and so on.

In industrial Functional Safety you might very easily work on requirements and definition for 2 years before you even think about what you might code, or even the device or platform you might be coding on.

I know of a mine winder job (Could kill 100 people in one go, so sort of like a passenger jet in risk profile) where the defining aspect of the design/build/commissioning critical path was Functional Safety, and it ran 10 years from very beginning to in service.

Imagine the most painful and anal waterfall process you could possibly dream of, and it is more onerous than this, plus you are exposed to being kicked backed to an earlier phase if certain problems are discovered.

If you are a move fast and break things, Mondays is pivot day and we like to actually roll some dice to decide what this weeks pivot will be, type of guy/gal, you are likely totally mentally not ready for how this needs to work, and probably don't want to be.

Plus if you come from a world where everything is a listener, and various other event driven paradigms, most of these people real struggle with real time highly deterministic systems.

This is because these invariably end up needing to be scanned logic, which looks stupid coming from this background. But, it is the best way that you can assure repeatable defined behavior, because event driven code is almost always of the type that ends up with an arbitrary order of execution, and this is not suitable for systems that have expectations of a highly deterministic nature.

There are zero cases for such devices where the answer to a problem is "just send that email again", to show the wagon wheel and/or drop a few frames or show some at lower resolution, or tell the user "just reboot at intervals of no more than 23 days and hold down the reset button while you boot", and so on.

And, some of these devices can do firmware upgrades OTA (not actually very common for somewhat obvious reasons), some need a special programming device within very close proximity and/or wired, and some are made with code in factory silicon and if you get it too wrong you recall them all for binning, at great expense.

I see another comment says that time to market for medical devices averages 12 years, and 75% of companies formed to make these devices fail - yeah I can totally see that, especially if it is a device that might roll out in the thousands to hundreds of thousands, the potential for harm, and for that harm to arise from software that either is specified poorly, or implemented poorly, is very large, extremely large.

I am a functional safety engineer, for well over ten years now, mostly industrial process and machinery, I hold certs from TUV Rhineland SIS and Certified Machinery Safety Expert TUV Nord.

But these are like one week courses, almost anyone that can pay attention could usually pass, though you need grades like 80% or 65% etc depending who runs the course you do.

More importantly (and written quite heavily into the standards) is you need to be competent, in the formal sense, which only comes from working with, or under, other engineers with suitable experience and background, and this might realistically be minimum 5 years, certainly no less than 3.

So moving into real time, embedded often, limited memory and CPU resources, need to know RF maybe as well, on it goes, do you as a well paid dev engineer want to go back to close to square 1 for x years, working in a way that will probably at best seem very antiquated to you, though most requirements are for good reasons when you understand them.

And ultimately, similar to other Fields of Functional Safety, the coding and all the computer stuff is probably easier learned by someone with extensive domain experience,

This is opposed to being an experienced coder (in most likely a different kind of code) and acquiring anywhere near the same domain experience in any reasonable time. eg in this case you are probably much more likely to to find medical people with training and experience that fell into dev roles to service the need, and it might be very difficult to compete with them, for what might be both real and perceived/cultural/"club" reasons.

There is more, but I am sure that is enough in the immediate context - not trying to be discouraging, just realistic.

Isn't H2 better because better lift and being a molecule of two hydrogen atoms it is not quite as slippery as helium and quite easy to make?

From wikipedia "lifting gas"

"Helium is the second lightest gas (0.1786 g/L, 14% the density of air, at STP). For that reason, it is an attractive gas for lifting as well.

A major advantage is that this gas is noncombustible. But the use of helium has some disadvantages, too:

    The diffusion issue shared with hydrogen (though, as helium's molecular radius, 138 pm, is smaller, it diffuses through more materials than hydrogen[4])."

The true art is in the architecture, which is the bit humans still generally control, not the tiny details.

Unless you would rather be a calligrapher than a novelist.

The key first step here is "Problem Identification" - the number of times I have seen where it is part way through a development, and only then it starts to become obvious that even if the specifications were good, they were not solving the right problem.

Users have a habit of describing their problem as the solution they think they would like to have, often being disastrously far from the actual need.