> What are you building?

This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs?

Hard to shake the feeling that this looks like one big pyramid scheme. I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering.

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It was, and is. But not universally.

If you formulate questions scientifically and use the answers to make decisions, that's engineering. I've seen it happen. It can happen with LLMs, under the proper guidance.

If you formulate questions based on vibes, ignore the answers, and do what the CEO says anyway, that's not engineering. Sadly, I've seen this happen far too often. And with this mindset comes the Claudiot mindset - information is ultimately useless so fake autogenerated content is just as valuable as real work.

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no."

[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic?

When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.?

I actually believe that software “could” be an engineering discipline but we have a long way to go

Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patterns, not just used established ones over time. This is fine with me, and when we apply the term "engineer" to work, I get a little uneasy, because I think it implies us doing something that most of us really don't want to do. That is, absolutely prove our approach works and will work for years to come. Just my opinion though.

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

- Edsger Dijkstra, 1988

I think, unfortunately, he may have had us all dead to rights on this one.

> What are you building?

I think AI really pushes this higher up the abstraction layer:

> What problem are you solving?

I've spent a good amount of my careering using engineering and math to solve specific problems, I'm usually adjacent to software teams.

What I've seen happen with agentic coding is that traditional software engineers keep focusing on using it to build software, while ignoring the problem they're trying to solve.

Meanwhile I've seen junior data analysts start interfacing with applications and tools they never dreamed of before, and delivering results to stakeholders in record times. Things that were previously blocked by engineering no longer are.

But many engineers today are not really problem solvers, they're software builders. The idea that solving the end users problem is the goal, not building them software, is incomprehensible.

And so they continue to struggle to use AI effectively because they're trying to build software with it. Which it's not terrible at, but it's really the wrong tool for that job.

Sometimes software is necessary to solve a problem, a few years ago, software was necessary for a fairly large problem surface area (though, to your point, even then a lot of software was not really built to solve those problems). Today that surface area is shrinking, and as economic constraints loom on the horizon, I believe it will increasingly be people who are solving problems (with or without AI) that will be the ones surviving.

> What are you building? Does the tool help or hurt?

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era.

I'm assuming you're saying these tools hurt more than help?

In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model.

PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined.

And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing.

It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.

People built a lot of great stuff with Ruby, PHP, Notes and VB. I don't know what the problem really is.

Personally I think that whole Karpathy thing is the slowest thing in the world. I mean you can spin the wheels on a dragster all you like and it is really loud and you can smell the fumes but at some point you realize you're not going anywhere.

My own frustration with the general slowness of computing (iOS 26, file pickers, build systems, build systems, build systems, ...) has been peaking lately and frankly the lack of responsiveness is driving me up the wall. If I wasn't busy at work and loaded with a few years worth of side projects I'd be tearing the whole GUI stack down to the bottom and rebuilding it all to respect hard real time requirements.

Maybe it's more about a rush to share how awesome it is that you compressed your time-to-release down to days and not weeks or months - when in reality that's a good thing in the sense that you get to a failure state much FASTER, and failure states are good, because that means that you get to iterate and get past those failures FASTER.

I don't think people were releasing at this pace, so the failure states are fast and furious so there is just that much more viability. I think the microslop windos failures lately are just them being the same "them" that they've always been .. just MUCH faster. (they just need to stop monkeying with windows and stop adding more features on top of an already shaky foundation.) Maybe we just need more of the stories like Anthropic working with Mozilla to squash 5x the amount of bugs in a similar time frame first, AND THEN "vibe a browser together from nothing but specification files and an army of bots in a weekend".

Hey Visual Basic is still there, and last time I checked it was still the goto option to do OLE Automation.

RoR is no longer at its peak, but is still have its marginal stable share of the web, while PHP gets the lion part[1]

Ok, Lotus Notes is really relic from an other era now. But it’s not a PL, so not the same kind of beast.

Well, also LLMs are different beast compared to PL. They actually really are the things that evocate the most the expression "taming the beast" when you need to deal with them. So it indeed as far away as possible of engineering as one can probably use a computer to build any automation. Maybe to stay in scientific realms ethology would be a better starting point than a background in informatics/CS to handle these stuffs.

[1] https://w3techs.com/technologies/comparison/pl-php

> It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is.

It is though. Picking the right approaches and tools makes more difference than anything else. Sure, you don't need the right tools if you can make the right choices - but it's much easier to pick a better methodology than to hire smarter people.

Agreed. I've been building software for 25 years+.

At some point I became so burnt out I couldn't look at an IDE or coloured text for that matter.

I found the way back by just changing my motto and focus... Find good people, do good work. That's it, that's all I want.

I don't care whether the 'property is hot' or what the market is doing anymore, I just build software in my lane, with good people around.

All (not some) of the most successful devs I've known in the sense of building something that found market fit and making money off it were terrible engineers. They were fairly productive at building features. That's it. And they were productive - until they weren't. Their work ultimately led to outages, lost data, and sensitive data being leaked (to what extent, I don't even know).

The ones who got acquired - never really had to stand up to any due diligence scrutiny on the technical side. Other sides of the businesses did for sure, but not that side.

Many of you here work for "real" tech companies with the budget and proper skin in the game to actually have real engineers and sane practices. But many of you do not, and I am sure many have seen what I have seen and can attest to this. If someone like the person I mentioned above asks you to join them to help fix their problems, make sure the compensation is tremendous. Slop clean-up is a real profession, but beware.

Exactly! I’ve noticed a resounding amount of people are writing the same pieces recently, it’s almost like everyone’s sounding their alarm for the upcoming tsunami. Who’s listening? Here’s my piece: https://humantodo.dev

Absolutely agree.

I'm watching a team which is producing insane amounts of code for their team size, but the level of thought that has gone into all of the details that would make their product a fit predator to run at scale and solve the underlying business problem has been neglected.

Moving really fast in the wrong direction is no help to anyone.

Engineering is two things:

1. Applied physics - Software is immediately disqualified. Symbols have no physics.

2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

>After five or six cycles it does become a bit fatiguing. Use the tool sanely.

That's increasingly not possible. This is the first time for me in 20 years where I've had a programming tool rammed down my throat.

There's a crisis of software developer autonomy and it's actually hurting software productivity. We're making worse software, slower because the C levels have bought this fairy tale that you can replace 5 development resource with 1 development resource + some tokens.

Perhaps this is the wrong place to plant this thought. Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void.

I once received a "bonsai" seed kit from a former boss during a holiday dinner. I think it was meant as a joke, but even now I'm not so sure. I planted those seeds anyway. I told some people about it and they immediately mocked me saying it was a waste of time and going to take 30 years. This interaction immediately said everything to me about the expectations and attitudes of others.

Obviously, they grew like any other plants and actually quite nicely. Of course they're a commitment, but not a huge one.

I just wanted some plants for my apartment and they fit the bill. In a few years I had good looking plants. A decade later, I still have them and they're now more recognizably "bonsai". My home now looks nicer, I have a story to tell, and I learned a little bit from a very low stakes hobby.

My point is, I think it's nice when people have projects. I think it's nice to see what comes of it. I guess my only regret is ever saying "I planted bonsai" too soon just because that's what the box said. I didn't know how else to describe what I had done that weekend to those people who threw theirs in the trash.

Software was an engineering discipline... at some places. And it still is, at some places.

Other places were "hack it until we don't know of any major bugs, then ship it before someone finds one". And now they're "hey, AI agents - we can use that as a hack-o-matic!" But they were having trouble with sustainability before, and they're going to still, except much faster.

I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It's a craft.

Largely a problem of VCs and shareholders. After my 12th year of "we'll get around to bug fixes" and "this is an emergency" I realize I am absolutely not doing anything related to engineering. My job means less than the moron PM who graduated bottom of their class in <field>. The lack of trust in me despite having almost a life in software is actually so insulting it's hard to quantify.

Now I barely look at ticket requirements, feed it to an LLM, have it do the work, spend an hour reviewing it, then ship it 3 days later. Plenty of fuck off time, which is time well spent when I know nothing will change anyway. If I'm gonna lose my career to LLMs I may as well enjoy burning shareholder capital. I've optimized my life completely to maximize fuck off time.

At the end of the day they created the environment. It would be criminal to not take advantage of their stupidity.

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era

Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?

As far as I can tell, the only reason agents exist is because large context increase the probability of context poisoning, purely by the inability of these models to actually make conceptual decisions about the context.

I was interested in making a semi-automous skill improvement program for open code, and I wired up systemd to watch my skills directory; when a new skill appeared, it'd run a command prompt to improve it and cohere it to a skill specification.

It was told to make a lock file before making a skill, then remove the lock files. Multiple times it'd ignore that, make the skill, then lock and unlock on the same line. I also wanted to lock the skill from future improvements, but that context overode the skills locking, so instead I used the concept of marking the skills as readonly.

So in reality, agents only exist because of context poisoning and overlap; they're not some magicaly balm to improving the speed of work, or multiplying the effort, they simply prevent context poisoning from what's essentially subprocesses.

Once you realize that, you really have to scale back the reality because not only are they just dumb, they're not integrating any real information about what they're doing.

Software engineering is real engineering because we rigorously engineer software the way real engineers engineer real things.

Software engineering is not real engineering because we do not rigorously engineer software the way "real" engineers engineer real things. <--- YOU ARE HERE

Software engineering is real engineering because we "rigorously" engineer software the way "real" engineers engineer real things.

Edit: quotes imply sarcasm.

I am just using Go at this point and stopped caring about my own opinions.

I live in the happy place in negligence. Go software has almost zero maintenance costs and it will continue to build my programs in 10 years with zero changes to my codebase being necessary.

I probably will never touch C++ again, even though CGo is the most painful FFI/ABI implementation I've dealt with.

Just today I tried to build a project that's using bergamoth and a shitload of broken C++ dependencies and decided to not give a damn after 5 hours of trying to fix crappy code that changed for whatever reasons between c++14 and c++15, well, or the dependencies are broken, or the dependency versions are broken, or the maintainer's code never compiled in the first place... I just don't care.

My hopes were higher during the conan peak days, but now the ecosystem is just so broken even with jinja and whatever build framework the new kids are using.

I guess I just really hate the C++ ecosystem, and the lack of self reflection in there about the self inflicted pain that shouldn't be necessary in 2026.

In regards to agentic coding: I am toying around with codestral:22b right now and xiaomi's mimo models, and am building my own local dev environment which makes this kinda nice.

It's local and I like it, sometimes need to use claude still but it's getting there. But I am delegating only the gruntwork, not decisions, so I use temperature usually below 0.3. My approach is to make this sandboxed per folder I run it in and that agents are only allowed to communicate via notes or tasks, so that they are forced to use better documentation. Specific roles don't have write access to certain things, e.g. coder can't touch tests, and tester can't touch code.

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

Just another reason we should cut software jobs and replace them with A(G)I.

If the human "engineers" were never doing anything precisely, why would the robot engineers need to?

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.