> this team, this business

These get overlooked so often. The way you build software if you’re at the helm vs the way you need to build it when dealing with a more/less capable team and business, especially if someone else will be doing the deployment and will need lots of consultations, is way different.

Yep that’s all “senior+ engineer” stuff at least and even those can be cut in half by quality. So maybe 25% of engineers have those attributes?

Do most companies even allow that kind of engineering to occur?

Prefacing that I’ve never worked at a faang. At more than half the companies I’ve worked out most of those decisions were made by non technical leadership for non technical reasons. Ranging from the reasonable(our predecessors signed a deal with Oracle a decade ago and violating it will cost us more than this project is worth) to the unreasonable(I had lunch paid for by this vendor so we’re using them now).

I also frequently ran into the problem of the process of doing that level of engineering requiring the business to make choices and being completely incapable of it. I could give 3-4 different plans with explicit tradeoffs, both in detail and with an executive summary, and what they meant for the company and even that low number of choices induced analysis paralysis in the management but they barred me from doing anything until they made the call.

It's been ten months since good models started landing and threatening our current job descriptions.

Do you think this is where it stops? This is where it begins.

Machines will be good at managing complexity too. You can't draw a line and say improvement stops here, because everything we've seen so far flies in the face of that.

I shudder to think what these models will be capable of in 24 months.

This whole week I've been dealing with incidental complexity created by shortcuts taken and edge cases not handled in code written in the before times, both in mine and in others'. I realized at some point yesterday that these kinds of shortcuts would no longer be accepted with competent LLM use.

The mental model was required when your brain was the only chance to reason about changes, answer cross-cutting questions (architecture), and develop a visceral feel for the project, because that's what you needed to write high quality software

It's hard to let that go, but you already had to in larger human organizations/collaborations where you might be assigned work on systems you never/seldom touch, or coming back to a project you haven't touched in a long time.

You don't need a mental model when you can automate the reasoning and the benchmarks that vet the reasoning. Your mental model is better spent pondering->reconsidering high level things like invariants, and then automating the the proof and implementation of those decisions.

Consider how you can just get Claude to start a workflow of 15 Fable agents to fan out over your system looking for correction/simplification/perf opportunities before spawn another wave of agents to vet the list of findings. How much time and energy and studying of the code would it have taken you to build and vet the same list?

Sadly many managers decided to do so and the damage is done

I love to say that

  Some managers didn't pass the Turing test

We built houses before we had nailguns but now that we have them they're pretty essential to building a house.

Have you looked at the machine instructions your compiler produces?

No? Why?

Because software languages are a pretty good abstraction.

To the extent that good abstractions are in place, you can avoid looking at code specifically.

Those don't perfectly well exist, so it takes a lot of self discipline and the right tools/methods, but invariably, AI will produce better systems.

That said, its very easy to produce slop, so well see much more of it.

But mostly, it will be AI from here on in, as a matter of productivity. There are some arguments on the margins but those will fade over the next few years.

'At minimum' - the 'power tools' are here to stay.

I don’t know, I could be wrong but I think one of the key aspects of system design which I don’t know if there is a lot of training data for us the “why” behind decisions. Separating out good design from bad isn’t always black and white and like the article mentions it’s about managing complexity and trade offs. It’s hard to capture in code/training data “we designed everything in a certain way but compromised in this one area because we were under time constraints and assumed we could fix it later”

A fun little exercise you can do is design a system and write some code and then ask LLM to explain why you wrote it that way. Results are varied and interesting but in my experience rarely capture the actual why behind decisions.

I'm the author: what's wrong with this article? No issues detected...

It was sold as a way to manage complexity but then made everything complex in a different way. For some problems, OOP makes sense, but for many I think it doesn’t. Unless you have a Rust like trait system that looks a lot like OOP but isn’t. That works well. Essentially don’t put state inside your classes, or you will be spending lots of refactoring time on moving variables up and down in the class hierarchy or throwing computer out of the window because a variable on second thought shouldn’t have been added near class Y.

You can tweak them to do so. I personally tweak mine to act like a disappointed stack exchange veteran.

I personally recommend, but I understand many people do not want to be pushed back by something they see as little more than a servant.

This setup does work to also have agents argue with each other. That can be very interesting, though you have to set them up to be very skeptical. Otherwise they will tend to read another agents assertion as authoritative off the bat.

I am convinced much of the harness/prompt engineering we are doing now will also be automated away. Within 5 years the best practices for the most popular use cases will have been found, automated and fully baked in.

Bing Bing Bing...

How often do engineers get a say in product direction?

Every one keeps saying that AI isnt moving the needle on the bottom line.

Well duh, code doesn't move the bottom line, features do, products do.

If you're building all the wrong things faster, all your doing is performing a speed run to a legacy code base.

Fair, but Software is very different from mech or chem eng though - enough so that it's worthy characterizing.

Same here, it was really tough on my eyes.

sorry guys, I'm setting up a dark/white switcher

No the AI cannot. Did you even read the article? The principles in the article are not rules that can be applied or handed to a prompt. They are questions, not answers. Questions that are impossible to answer and that have no right answer except by human judgement in a concrete context.

Even a human could not “manage complexity” if it’s not in the right context. This is not about AI vs. human capabilities.

Software engineering was never about writing "just" code. Simply writing code was not enough in most business environments.

Spitting out code as fast as our fingers could type has never been the job. There has always been a lot of think time.

Which is why the productivity of people of people has never been correlated with typing speed.

In other jobs productivity is correlated with typing speed and in those jobs a typing speed like 60wpm is part of the job requirements.

It’s not AI-generated. I’m the author. I wrote it in about an hour this morning, then spent another twenty minutes or so fixing a few mistakes. There are probably still a few more in there :)

Sure but the HN discussion of just the titles is already great.

Technically it is not a reasoning machine. If it was a reasoning machine then we would not see results like this:

> To systematically investigate the role of end-user semantics of derivational traces, we set up a controlled study where we train transformer models from scratch on formally verifiable reasoning traces and the solutions they lead to. We notice that, despite gains over the solution-only baseline, models trained on entirely correct traces can still produce invalid reasoning traces even when arriving at correct solutions. More interestingly, our experiments also show that models trained on corrupted traces, whose intermediate reasoning steps bear no relation to the problem they accompany, perform similarly to those trained on correct ones, and even generalize better on out-of-distribution tasks.

https://arxiv.org/abs/2505.13775

Beyond Semantics: The Unreasonable Effectiveness of Reasonless Intermediate Tokens

Because it’s not about being “good at things”. You missed the whole point of the article. It’s not about AI vs. human capabilities, even a human could not build software if they are not in the right context.

Here’s an example: back in the 2000s, everyone was afraid programming was going to get outsourced to India or other countries. It didn’t happen, Sillicon Valley continues to spend billions to import engineers to work in person even though it’s 10x cheaper to hire remote outsourcers in India who are just as skilled programmers. Why do they spend 10x to move physical bodies to the office? Because it’s impossible to write good software without being in the physical context of the problem domain and team.

Similarly you cannot outsource to AI, because it cannot have complete context. No matter how good AI is, the problem is not mechanically solvable.

It can't reason at all. This has been shown time and time again, and is inherent to the very nature of how LLMs work.