mattmanser

It had the opposite effect you're describing. Not quite everything has transitioned though, for example there are little bits of the limited company maintenance process that seems to be on old systems.

The only big hiccup that I've personally seen is that they've never really solved the "user id" problem, we seem to have had 3 different schemes in that time period. The early one, the government gateway id, I at one point had 3 different ids because some departments screwed up and issued you a new one the first time you used their service, when you already had one.

There's a lot of languages where that's nowhere near as simple as you make it sound. Floating point, decimals, etc.

Then there's other little quirks like rounding rules: https://en.wikipedia.org/wiki/Rounding

Basically, adding numbers together is exactly the sort of thing AIs still muck up spectacularly, precisely because they either fail to understand the context of the problem, or fail to ask about an assumption they make.

That you've had so many replies and no-one else has even mentioned this is in itself worrying.

Your own example proves your point is wrong.

Sometimes it's building a house, sometimes it's writing a book, sometimes it's the difference between a Ford and a kit car, sometimes it's how you build a bridge.

None of them stand up to full scrutiny. You can pick every single one apart.

That's not the point of analogies. The point is to explain just one of the many aspects of software engineering in a more understandable format to the listener. Software engineering is nothing like building a physical thing. But some of the many, many problems and complexity you hit have physical product analogies.

Don't stretch analogies too far as they all pop.

The author then picked them out, not the AI. For curiosity I assume.

https://eu-mayors.ec.europa.eu/en/news/stockholm-sweden-heat...

He's now (famously) said that the only thing he ever actually used GasTown for was to code on GasTown.

And then get it to review the code, where it'll pickup a few edge cases.

But I don't really get the attitude that we shouldn't write code anymore, for me it's often quicker to write the code than to explain to the AI how to write it.

Sometimes when I'm.sitting there watching it chug away for 5 minutes over what should be a three line change, I'll just stop it and do it myself, and then at that point I'll often take over completely for a while.

As 80% of enterprise software is CRUD with a bit of sprinkling of user authorization and tenant customisation. But subtly different for every business domain. It's mainly what properties the models and validations have that are different.

When you add a new module or whatever most of the code you have to write is rote code.

And sonnet can handle that crap just fine, you just point it at a similar example in the code, it picks up your userContext convention, how you're doing i18n, etc. and you're done.

I like saying that enterprise code is often shallow but wide. I must have written at least 4 purchase order systems in my career that are all completely different but almost exactly the same.

tbh if you want to scratch the pirate-y itch, Assassin's Creed Black Flag is excellent, if just for the sea shanties.

Which has itself just had a remake released for it I see! I don't keep up with games these days.

8 years is long for IKEA furniture, usually something has irreplaceablely broken by then.

IKEA also refuse to sell you spare parts.

Give me real furniture anyday.

As I understand it, there is (or was) a step where they ask people what's the 'better' response.

These linguistic forms sound good the first time you hear themz even if they are rare in real speech, so rapidly got trained in.

Now they distill off previous models, I imagine these weird linguistic forms are quite hard to get rid of.

If you look at the 90s + 00s, everything was moving towards unified systems, things like small talk, winforms, spring, asp.net, etc. were moving everything into the IDE, you used one language, one framework, one build system. Then people started adding javascript, but even that was getting semi-unified as people coalesced on jQuery, jQueryUI, etc.

Then something happened in the late 00s/10s, and suddenly we had SPAs and noSQL, then microservices, then k8s and now we're here, in what is a mish-mash of 10/20 different systems with 10/20 different attack surfaces.

As my own off-the-cuff guess of what happened, I think perhaps people tried to apply the Unix philosophy, but without a central committee keeping everything aligned it's really not worked.

Serving an interactive page that stores data over sessions should be a trivial solved problem at this point, and instead we've somehow made it where often the scaffold is vastly more complicated than the actual business logic.

On top of that, the default place for a console in VS Code is at the bottom, now I'm down to 25-30 lines if I have that open.

And then there's heavier IDEs like IntelliJ, Visual studio, etc.

They might have two or three tab lines at the top, a row used for class navigation (that I've just realized I've never, ever used), an extra row or two of quick action bars, a row of extra tabs at the bottom for navigating between consoles/call stacks/locals/error lists, 2 info bar rows at the bottom, and sometimes two or even three scroll bars stacked on top of each other.

All of a sudden you're down from 30 lines visible to 17, which is my actual visible lines of code when I have debugging running.

So it's a pretty much pointless test now.

But all my refactors have been in statically typed languages.

To speculate on the reason why, which the GP asked, I think perhaps it is two things. It's the same satisfaction from tidying a room or your workbench. But it's also slightly narcissistic unfortunately. I think you've shown you're better than the other programmers. Much, much, better when you end up with massive reductions in TLOC.

And with tests, the irony is that the resulting code is often so much easier to reason about, you start spotting really obvious bad assumptions in the original implementation.

It's one of the reasons I've always been fairly skeptical about the true value of unit tests (integration, I get). That and the fact that projects I've worked on that did have unit tests catch like 1 bug a year. Maybe it's just the size of systems I traditionally work on (smaller teams, or even 1 person teams, so man-years worth of effort rather than decades or centuries).

https://claude.com/blog/the-new-rules-of-context-engineering...

Discussion:

https://news.ycombinator.com/item?id=49051361

It's an insane way of managing what is essentially configuration in this day and age, literally throwing away all our hard-earned lessons of the last 3 decades.

Worse still, it'll just use it randomly, and you have to notice it's done it.

"The user never wants to use ORDER BY Timestamp, I'll add this as a memory"

"For this object, JUST FOR THIS OBJECT! NOOOOOOOOOOOO!!"

Like "It's not x, it's y". It actually has 4 or 5 of those counter-factual, linguistic pause, factual patterns it uses.

"The [goal/ambition/etc.] is larger: statement", is another oft repeated phrase.

And then generally, it loves dramatic pauses in statements like "x exists in y; in practice z". It's the weird punctuation it uses. A massive overuse of colons and semi-colons instead of words like and, but, because, althoughy etc. that humans normally use.

    - Video and audio generation and editing through APIs and private weight access. (“FLUX 3 Video”)
    - Action prediction through selected research and commercial partners, beginning with mimic robotics (“FLUX-mimic and FLUX 3 Action”)
    - Image synthesis and editing through APIs and private weight access. (“FLUX 3 Image”)
    - Open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction. (“FLUX 3 Dev”)

All the studies show it's not an over-reaction, you're 400% more likely to have an accident. It is extremely dangerous and it's not an over-reaction, the more people do this, the more people die. It's simple maths. If you're doing extended programming sessions, you're not paying attention to the road like you should be.

And no, talking to a passenger is not as dangerous as it's a different cognitive load.

It'll take you 20 seconds to google this, please do and stop putting everyone else in jeopardy.

The model which everyone else raves about and is wildly successful with legions of programmers virtually demanding access while abandoning ChatGPT and Copilot in droves, is rather dumb?

Have you considered that it's more likely that you're doing something wrong?

https://etsc.eu/tiny-proportion-of-drivers-understand-danger...

As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.

And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.

As it reads more to me like it's Douglas Adams humour, i.e. 1980s humour.

British, post-Python absurdist humour or whatever you'd call it.

Did they fix that, as that for me was what actually made codex worse.

DTOs are one of the big code smells of a code base that does little but will be full of boilerplate. As soon as you see an automapper or a folder of DTOs you know you're in for some serious pain.

On the plus side you also know you can reduce the codebase by about 75%.