The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer. Having architects who didn't interact with the code always produced map/territory mismatches.
I love to say that
Some managers didn't pass the Turing testNo? 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.
> No? Why?
> Because software languages are a pretty good abstraction.
No, it’s because compilers produce deterministic output. I am so tired of this argument.
If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.
It's less about writing code now but we're lying if we try to pretend it was a distraction and not a big part of the real work.
And every claim about what the job actually is or was all along has an implied (for now) at the end of it.
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.
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.
The site just goes into a reload loop on iOS?
However I think it's aggrandizing what human engineers actually do with remarks like "Engineers own tradeoffs." My experience is that certainly less than half of the employed software engineers don't actually give a real analysis to questions like:
"Given these constraints, this team, this business, this infrastructure, this budget, these risks, and the expected evolution of the product, what is the most appropriate way to implement X, today?"
Thus I think AI is more able to replace the average engineer more than this article admits, however the inadequacy of "average engineering" will be much more apparent now: codebases can become large/complex enough to be unwieldy in months now when it used to take 5 years [a timescale where accountability is effectively impossible].
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.
I've been hearing this "writing code is not what being an enginner is" mantra for years like some sort of gotcha. (It was prevalent even before AI, and I think people underestimated a lot how many people were simply incapable of writing code even given all the specs and design choices.)
People are shouting “yeah the hard part was never writing code, it was managing complexity” as a sort of last hurrah before AI engulfs them.
This is reality: not only can AI write code. It can manage complexity.
Prompt: read the article in this thread then execute its principles on my codebase. Write a harness and programmatic procedures that will trigger you to respond with the articles philosophy to code changes. Be vigilant and monitor every aspect constantly.
I would say for the above prompt, AI is about 60 to 70 percent as a good as a human now. A year ago it was 20 percent. The gap is closing.
a2ff6eeb0•57m ago
It's not as good at system design as writing code, yet. But it feels like it's better than most of my coworkers.
I think in a few months, system architecture will have its Claude Code moment, and humans will be outclassed.
VohuMana•24m ago
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.