gctwnl

Part #6 of a series of lab notes on an experiment: how good is AI-generated code really? The code was not very good, but Claude's reaction to the audit wasn't all that bad.

By the way, there is caching (cache TTL is hort but during sessions it is active). E.g. Settings Status Config Usage Stats

  Session
  
  Total cost:            $15.59
  Total duration (API):  18m 3s
  Total duration (wall): 2h 13m 16s
  Total code changes:    232 lines added, 80 lines removed
  Usage by model:
       claude-opus-4-6:  1.5k input, 41.8k output, 26.4m cache read, 212.6k cache write ($15.59)

What is that, exactly?

Why was this flagged? The article is a serious attempt at observation and analysis.

That is interesting. $200/month for >$10k at API-pricing? That's way more than the 2.5x-12.5x the article observes.

Wait, what?

Yes, th enumber is based on subsidised subscriptions and he article makes that clear.

There are no revenue estimates in the article). Only as serious as possible estimates of cost per task.

The data is given and not made up. The data based on actual use and on analysis of public numbers.

The no-caching is explained in the linked conversation. The numbers are from actual use.

Short 3 minute excerpt of a talk on fundamental properties of IT as well as fundamental properties of humans that influence design decision making in complex (IT) landscapes. Only slightly tongue-in-cheek.

Why, if the author asks it to summarise a single webpage and gives the link should ChatGPT go out and load 5 more (one is the same page again, the others short overview pages, so won't have influenced the result much)

And why all this talk about trying to engineer a prompt so that in the end the result is good? Should an actual usable system not just handle "Please summarise [url/PDF]"? That is, I suspect, what people expect to be able to do.

Definitely. Otherwise it would have required a lot more than a single blog post. It is an observation, not anything rigorous with a large number of examples, and decent statistics.

Generative AI models 'memorise' some training data. This can be sought-after so we get reliable answers, but it is also a bad thing: training data leakage, plagiarism. The problem? The good and the bad are the same thing.

I would consider this realistic service design, just as Meta’s Cicero (plays blitz Diplomacy) is smart design. It might work as a service.

What the answer glances over is that even with just 3% of the time requiring human assistance (2 minutes out of every hour) the term ‘autonomous vehicle’ is not really applicable anymore in the sense everybody is using/understanding that term. The idea behind that term assumed ‘full’ autonomy. Self driving cars. And there is no reason to assume that this is still in sight. The answer puts that ‘self-driving car’ on the shelf.

PS. Human assistent seems to me a difficult job, given the constant speed and concentration requirements.

Bridges the gap between all the explanation of the internals of transformer architectures etc. and the (good/bad/imagined) uses. Suitable for non-technical people, but does explain what GPT does and what that means.

Article using psychology research insights on the subject of convincing others, e.g. IT architects convincing management what the 'right thing to do' is

Because loans are generally a safer investment than stock (ownership) with more certain returns.

And when you can get good returns from loans (high interest) stock gets relatively less attractive and hence the stock prices drop to match again the risk versus reward equilibrium (cheaper stock means less money invested means less risk for the same returns like dividend or stock growth)

This is why stock prices react almost immediately to interest rises.

The key investment calculus is always risk versus reward.

Secondary: the cost of doing business also goes up.

One of the more interesting aspects is that the idea of what (enterprise) 'architecture' is, depends on who you talk to. There is an interesting relation between agile and architecture.

https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meani...

Nobody I take serious takes TOGAF serious.

A while back Grady Booch was asked on Twitter what architecture books he would suggest. He replied with three images of sets of covers of what was on his bookshelf (some 45 books in all, I think). All of them more software architecture style books. One EA book: Chess and the Art of Enterprise Architecture. Which I personally found noticeable.

The one one the rack

Road maps are generally pretty useless. They are a form of trying to predict the future. Good Life Cycle Management is of course OK, but you cannot predict what you will need a year (or two) from now.

The article is simply saying that with the growth of IT, change is getting harder (existing landscapes have inertia), something the top is slow (if at all) to accept. That makes the role of the person trying to explain that (and why) change is getting harder a more frustrating one.

Agreed. And in my observations, these architects were engaged deep in technical discussions. They weren't the 'powerpoint-slide' types.

The architects that think enterprise architecture is about designing enterprises and not about managing the effects of complexity that comes from IT at enterprise scale are generally the useless ones.

Sounds like a super example of 'loosely coupled spaghetti'

That is probably a good example of the _bad_ architects the article mentions

Architects that sit constantly in that abstract realm are useless (and they are not architects in my view). But there are architects that do exactly what you describe in your ideal world.

Architecture is simple: it is that in your landscape that is hard to change. Making design decisions that are wise is the task of an 'architect', which is just another word for 'designer' (though it has been sold as something else). How you organise architecture processes depends on how you organise development, but the subject is the same. For instance, too much yagni is awful: everybody ends up waiting when something is needed that was not clear before. Finding those elements that improve your future speed is part of a good architecture process. Secondly, users are very focused on features and defects, but architecture is potential features and defects, and users are not a good source for those.

Definitely not