Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- One question missing from the list, and it’s the first one I tend to ask… do we really need this? I’m not sure I’ve ever seen an agent pushing back on a request.by raevn
- 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.
by zer00eyz - The real wild shit I'm seeing and having trouble reconciling with continuing my career in this field is that there seems to be a majority contingent of C-suite out there that is absolutely obsessed with force-feeding their organizations AI.
As an software engineer, I will readily admit that LLMs have greatly increased my output - especially on the menial work.
But now we have leadership telling everyone to "use moar AI" on everything, everywhere. I literally have observed folks dropping into incident Slack chats saying things like, "hey all - i asked Claude about this issue and then i had it write a solution. here's the PR." This feels like the kind of thing that should be a fire-able offense, but instead they're getting shout-outs from the CEO.
Hell, the next time I go on vacation, I think I could put Claude Code on YOLO mode for 2 weeks and I'd probably come back to find I'd been promoted.
I do not know how this is going to end, but I have a feeling it's going to get way darker before it gets better.
by ryandvm - Thanks, might be the best blog I've read in 2026. AI can of course do architecture as well but oh boy will you have a bad time when your application breaks and neither you or AI can fix it.by coredev_
- These software engineering analogies are getting tiresome.
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.
- 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.
by znnajdla - Always reminds me of why OOP came about in the first place; it was a way to manage complexity and led to much better and grander software. Now nobody talks about OOP because abstractions are built into just about everything.by karim79
- 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.by huijzer
- I started to look around the site and opened this: https://hack8s.com/409/ziglings-all-exercises-solve-v0-16-0
The site just goes into a reload loop on iOS?
by thi2 - I'm the author: what's wrong with this article? No issues detected...by justorius
- Sometimes these tradeoffs involve half a dozen over a few lines of code. And that’s where I’m hesitant to let an agent work. It’ll do fine with creating correct code. And you can somewhat constrain it to think about one other thing. But it loses track, ignores constraints, cheats, and do you layer complexity on top to prevent this? Or just look at a dozen lines of code to fix it?by softwaredoug
- > By algorithmic thinking, I mean defining a set of basic rules to follow and applying everyday...
This is actually kinda a good suggesting for everyday life as well. Many problem people face are too complex to figure out without systematic analysis, and with this method of thinking, complexity can be simplified.
Of course you have to do some swaps:
BTW: Is this article was about LLMs induced identity crisis? I noticed quite a few blogs written in a similar color trying to realign themselves in the new world of AI.> Understand data flows -> Understand whats, hows and whys > Choose appropriate data structures -> Choose appropriate tools > Reason about time and space complexity -> Reason about cost and effectivenessOf course that's a reasonable thing to consider, but in addition to that, I think it's also kinda useful to remember why you started as a software engineer to begin with, what were you planning that drives you to select this path? Will AIs be a blocker of that plan, or a enhancer?
by nirui - Software complexity grows superlinearly, if not exponentially as you add components.
There are things an engineer can do to flatten the curve - that is OP's complexity management idea - but complexity growth can never be linear as long as you are adding to the software.
I made a model/theorem for this that I posted on X: https://x.com/i/status/2027771813346820349
Code generation has exposed that verification is the central problem of software engineering. And I think it always has been.
Defining what is "correct" can be hard enough, let alone building a system that lends itself to verification, let alone spending the time to verify. Releasing software and letting users find bugs is therefore a very efficient strategy, because it spreads the burden. But you have to ride the line between losing users and getting enough feedback to find and fix the bugs that matter.
As we confront whether AI might take our jobs, I take some comfort in the idea that the world might be too complex for even the largest, best trained AI we can imagine. At a certain point, you need to simulate the whole world (or some substantial portion of it) and the cost/benefit of trying to do all that with compute may not be worth it versus using the real world (that is, humans) as your verifier.
by wyum - AI can also generate the architecture for you based on the requirements, and ask the necessary clarifying questions.
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.
by a2ff6eeb0 - 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.
by VohuMana - Lost me at the first assumption. People can argue about how useful AI is, but it's obviously not essential because we somehow managed to write code without it a few years ago. I would even say the code was better back then.
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.
by cobbal - 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.
by bluegatty - Sadly many managers decided to do so and the damage is done
I love to say that
Some managers didn't pass the Turing testby p0w3n3d - We built houses before we had nailguns but now that we have them they're pretty essential to building a house.
- 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?
by hombre_fatal - 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.by sunshowers
- The complexity stuff is all absolutely true.
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].
by zug_zug - 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?by therealdrag0
- I do exactly that, I am 100% on board with you.
Ignoring business and team scale in that question brought big damage to businesses, by developing software overly complex at times.
And the cost is of course hidden behind a salary of developers, so hard to say
- 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.
by echelon - > 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.
by KronisLV - 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.
by lovich