What's old is new again. There's a whole generation of users that never experienced those days. OS X 10.1 is 24 years old now. So for them, this is all brand new and innovative.
> Just genuinely wondering, since it feels like maybe 2 years of start/stops/changing priorities.
I think it's exactly this. Apple got caught with their pants down on AI, had to shift quickly and that's what got us last year's announcements that never came.
Well, it still isn't ready, so they needed something to give this year since they are so committed to an annual release cycle (which I think is a mistake IMHO), so we get a design change & some love for the iPad.
OTOH, I like where Apple is going with private, on device AI. So if they need some more time to make it useful and polished, totally fine with me. I'd prefer they don't ship a half baked, hallucinating piece of crap. I personally don't/won't use any of the AI "features" so for me personally, it's refreshing to have a tech conference keynote not be "AI AI AI AI." It's worse than when blockchain was all the rage.
> Your smoking gun is to not use the app in the most intuitive and obvious way?
Search isn't the most intuitive and obvious way to everyone. Just adding a search function also isn't an excuse to just totally ignore good UX design and information hierarchy.
I've been a sysadmin my entire career, and still do end-user support occasionally. You'd be surprised how few people use the search function, for anything, on their computers. Just opening the windows start menu and showing them they can search there is like black magic to a frighteningly large amount of people.
I've met fellow Mac users that don't even know spotlight exists, and navigate through the OS and every app via mouse and clicking around.
So yeah, just throwing a search box in your app as an excuse for ignoring the experience of navigating it any other way is bad UX design.
There's a search bar in the System Settings app, you don't need to know what Spotlight is.
I'm staying with family and just handed my 64 year old mother who has never used a Mac my Macbook Pro with the settings app open, and after explaining the concept of default browser in non-leading language (not mentioning the word default), her first thought was to click Display.
When nothing familiar was there her next thought was to click Search and then type in Browser and she made the connection of "Default Browser" to the concept I mentioned immediately.
yeah, I'm one of those who usually ignores any built in search option. I just default to assuming that it's an adware infested trap that will provide no value, only "engagement". Windows and Google conditioned this behaviour in me over the years.
By the way, macOS has a super useful search field under "help" in the menu bar. It searches among all menu items in the current app and even shows you where they are. Very non-obvious, but once you try it, you don't understand how you lived without it.
> I would like to hope the orange site approaches this topic with more substance.
You won't find that here if Microsoft/Windows is in the title. HN will default to FUD on anything from Redmond.
How many here complaining about analysis in the photos app on Windows also sync all their photos to iCloud or Google Photos, which does the exact same thing? I bet it's a lot.
> The fact they are so popular is indicative that most people value the service over their privacy, or simply don't care.
Or, the general populace just doesn't understand the actual implications. The HN crowd can be guilty of severely overestimating the average person's tech literacy, and especially their understanding of privacy policies and ToS. Many may think they are OK with it, but I'd argue it's because they don't understand the potential real-world consequences of such privacy violations.
> Or, the general populace just doesn't understand the actual implications.
That might've been the case in the first generations of ad-supported business models on the web. But after two decades, even non-technical users have understood the implications of "free" services.
IME talking to non-technical people about this topic, I can't remember the last time someone mentioned not being aware of the ToS and privacy policies they agree to, even if they likely hadn't read the legalese. Whereas the most common excuses I've heard are "I have nothing to hide", and "I don't use it often".
So I think you're underestimating the average person's tech literacy. I'm sure people who who still don't understand the implications exist, but they're in the minority.
> get the encouragement and space to independently develop the experience they need to break out of the "vibe coding" phase?
I wonder this too, as someone who is entirely self-taught, when I started escaping “tutorial hell” was the hardest part of the journey, and took quite a bit of both encouragement and sheer willpower. Not sure I would have ever went beyond that if I had LLMs.
I worry for Juniors, and either we’ll need to find a way to mentor them past the vibe coding phase, or we hope that AI gets good enough before we all retire.
> But what if you only need 2 kentonv's instead of 20 at the end? Do you assume we'll find enough new tasks that will occupy the other 18? I think that's the question.
This is likely where all this will end up. I have doubts that AI will replace all engineers, but I have no doubt in my mind that we'll certainly need a lot less engineers.
A not so dissimilar thing happened in the sysadmin world (my career) when everything transitioned from ClickOps to the cloud & Infrastructure as Code. Infrastructure that needed 10 sysadmins to manage now only needed 1 or 2 infrastructure folks.
The role still exists, but the quantity needed is drastically reduced. The work that I do now by myself would have needed an entire team before AWS/Ansible/Terraform, etc.
I think there's a huge huge space of software to build that isn't being touched today because it's not cost-effective to have an engineer build them.
But if the time it takes an engineer to build any one thing goes down, now there are a lot more things that are cost effective.
Consider niche use cases. Every company tends to have custom processes and workflows. Think about being an accountant at one company vs. another -- while a lot of the job is the same, there will always be parts that are significantly different. Those bespoke processes often involve manual labor because off-the-shelf accounting software cannot add custom features for every company.
But what if it could? What if an engineer working with AI could knock out customer-specific features 10x as fast as they could in the past. Now it actually makes sense to build those features, to improve the productivity of each company's accounting department.
It's hard to say if demand for engineers will go down or up. I'm not pretending to know for sure. But I can see a possibility that we actually have way more developers in coming years!
> I think there's a huge huge space of software to build that isn't being touched today because it's not cost-effective to have an engineer build them.
That's definitely an interesting area, but I think we'll actually see (maybe) individual employees solving some of these problems on their own without involving IT/the dev team.
We kind of see it already - a lot of these problem spaces are being solved with complex Excel workflows, crappy Access databases, etc. because the team needed their problem solved now, and resources couldn't be given to them.
Maybe AI is the answer to that so that instead of building a house of cards on Excel, these non-tech teams can have something a little more robust.
It's interesting you mentioned accounting, because that's the one department/area I see taking off and running with it the most. They are already the department that's effectively programming already with Excel workflows & DSLs in whatever ERP du jour.
So it doesn't necessarily open up more dev jobs, but maybe fulfills the old the mantra of "everyone will become a programmer." and we see more advanced computing become a commodity thanks to AI - much like everyone can click their way through an office suite with little experience or training, everyone will be able to use AI to automate large chunks of their job or departmental processes.
If we shiver at the sight of some of those accounting-created excels, which we only learn about when they fail and they can't understand them anymore, wait for them to hand over a vibe-coded 200k loc Python codebase "which is not working anymore" and nobody had ever reviewed a single line of code.
> I think we'll actually see (maybe) individual employees solving some of these problems on their own without involving IT/the dev team.
I agree, but in my book, those employees are now developers. And so by that definition, there will be a lot more developers.
Will we see more or fewer people whose primary job is software development? That's harder to answer. I do think we'll see a lot more consultant-type roles, with experienced software developers helping other people write their own personal automations.
> I think there's a huge huge space of software to build that isn't being touched today because it's not cost-effective to have an engineer build them.
LLMs don't change that. If a business does not have the budget for a software engineer, LLMs won't make up budget headroom for it either. What LLMs do is allow engineers to iterate faster, and work on more tasks. This means less jobs.
If a business has the budget for 1 or 2 engineers though, they might be able to task them with work that previously required 5-10 engineers (in theory, anyways).
Right, but even the way you opted to frame this discussion is based on the idea that there is a drop in demand for software engineers. You need less engineers, not more. A few can get more done, but you need fewer to accomplish your tasks too.
This is like claiming that there are fewer people who work in construction now than in the year 1000 because a machine can do what it would have literally taken 100 people to accomplish back then.
But what has happened instead is that we are now building much more buildings and much more complex ones than we ever would have even conceived of back then. The Three Gorges dam required the work of thousands or even tens of thousands of people when it was built, and it would have required the work of millions in the year 1000. But it didn't actually generate millions of jobs in the year 1000: it was in fact never even conceived of as a possibility, much less attempted.
Of course, the opposite can also happen. The number of carpenters has reduced to almost nothing, when it used to be a major profession, and there are many other professions that have entirely disappeared.
I didn't frame it that way - perhaps you are thinking of the person you replied to?
Nevertheless, I don't think they are trying to frame it that way, either. The point is that making software development easier can actually increase the demand of software engineers in some cases (where projects that were previously not considered due to budget constraints are now feasible).
> I didn't frame it that way - perhaps you are thinking of the person you replied to?
You did. You explicitly asserted the following.
> If a business has the budget for 1 or 2 engineers though, they might be able to task them with work that previously required 5-10 engineers (...).
In your own words, a project that would take 5-10 engineers is now feasible to be tackled with 1 or 2. Your own words.
> (...) The point is that making software development easier can actually increase the demand of software engineers in some cases (...)
I think that's somewhere between unrealistic and wishful thinking. Even in your problem statement, "making software development easier" lowers demand. Even if you argue that some positions might open where none existed before, the truth of the matter is that at the core of your scenario lies a drop in demand for software engineers. Shops who currently employ engineers won't need to retain as many to maintain their current level of productivity.
> In your own words, a project that would take 5-10 engineers is now feasible to be tackled with 1 or 2. Your own words.
That statement != lower demand for software engineers.
If a firm needs to perform project X that previously cost 10 engineers to do, but they only have the budget for 2, they will not tackle that project. Engineers used = 0.
However, if due to productivity enhancements with AI, the project can now be done with just 2 engineers, the company can now afford to tackle the project. Engineers used = 2.
That is the point that the person you were originally replying to was making.
> Even in your problem statement, "making software development easier" lowers demand.
Incorrect, as shown above.
> Even if you argue that some positions might open where none existed before, the truth of the matter is that at the core of your scenario lies a drop in demand for software engineers.
I see what you are trying to say, but it's not that clear cut. The fact is, no one knows what will actually happen to software engineering demand in the long run. Some scenarios will increase demand for engineers, others will decrease it. No one knows what the net demand will be, everyone is only guessing at this point.
> If a firm needs to perform project X that previously cost 10 engineers to do, but they only have the budget for 2, they will not tackle that project. Engineers used = 0.
0 on that Project, but those 2 engineers will still be used on a different Project that needs just 2 Engineers.
BUT a company that sees that project as a critical part of the bussines and MUST tackle that project, will only need the 2 engineers in the payroll. Or hire just 2 instead of 10.
Engineers not hired = 8
Or.. maybe they don't really need that project that needs 10 engineers. They are ok as they are today, but they realize that with AI, they don't need those 2 engineers anymore to produce the same output, probably can be handled by just one with AI assistance.
But now every firm has access to AI. If a firm that doesn’t fire people but instead simply boosts productivity, they will out compete their competitors. The only way to compete with that firm is to also hire enough employees and give them AI tools.
After 30+ years in the software field, and a user for 40+, having at times heavily customized my desktop or editor, for example - I've concluded that the best thing for most apps is for me to learn to use them with stock settings.
Why? Inevitably, I changed positions / jobs / platforms, and all that effort was lost / inapplicable, and I had to relearn to use the stock settings anyway.
Now, I understand that some companies have different setups, but it might just make more sense to change the company's accounting procedures (if possible) to conform to most accounting software defaults, rather than invest heavily in modifying the setup, unless you're a huge conglomerate and can keep people on staff. Why? Because someone, somewhere will have to maintain those changes. Sure, you can then hire someone else to update those changes - but guess what? Most likely, unless they open-source their changes, no LLM will have seen those changes, and even if they are allowed to fine-tune on it, they'll have seen exactly ONE instance of these changes. Odds they'll get everything right, AND the person using the LLM will recognize when it doesn't go right? Oh right, they invested in hundreds of unit tests to ensure everything works as expected even with changes, and I'm the tooth fairy..
This just isn't true and will probably never be true. Using all the defaults is... probably optimal in the general sense and when things come to scale, but most companies (or just leadership) at some point want to leave the "standards" with custom design or additions. Also, any company providing payroll/accounting/ software has an inherent interest in going against standardization and providing features to promote lock-in.
There are good arguments to just conform. But it is in fact true nevertheless that many companies and teams continue to choose bespoke workflows over standardized ones. So I guess there must be something driving that.
I don't actually think this is going to take the form of LLMs implementing custom patches to off-the-shelf software. I think instead it's going to look like LLMs writing code that uses APIs offered by off-the-shelf software to script specific workflows.
It's interesting that you bring up accounting software as an example. In jurisdictions where legal requirements around it are a lot more specific than in e.g. US, accounting suites usually already come with a lot of customization hooks (up to and including full-fledged scripting DSLs), and there are software engineers and companies who specialize in using those to implement bespoke accounting requirements.
I admit I have no specific knowledge of accounting and just meant to reference any random department that isn't engineering.
(Though I think it's true of engineering too. We all have our own weird team-specific processes for code reviews and CI and deployments which could probably use better automation.)
But even where lots of customization exists today (such as in engineering!), more is always possible. It's always just a question of whether the automation saves as much time as it took to build. If the automations can be built faster, then it makes sense to build more of them.
This is precisely why I compare this technological revolution with the electronic spreadsheet. Before the electronic spreadsheet, what used to take several accountants several days to "compute a whole spreadsheet" after changing "a few inputs" is serviced by a single accountant in a few minutes. That kind of service that was only available to enormous firms with teams of dozens of accountants is now available to firms with a technically proficient employee who do that kind of accounting as only a small part of their role.
It took time as different firms adapted to adopt computer technologies in their various business needs and workflows. It's hard to precisely predict how labor roles will change with each revolutionary technology.
I work for SMEs as a consulting CTO, and this is exactly where I see things going in this domain. I can take care of workloads that would've been prohibitively expensive in the past. In the case of SMEs, this may cover critical problems whose resolution can unlock new levels of growth. LLMs can be an absolute boon for them, and I'm fairly optimistic about being able to capitalize on the opportunity.
Though arguably cloud infra made it so that a lot more companies who never would have built out a data center or leased a chunk of space in one were spinning up some serious infra in AWS or Azure -- and thus hiring at least 1-2 devops engineers.
Before the end of zero interest rate policy, all the sysadmins I knew who the made the transition to devops were never stuck looking for a job for long.
To be clear, the number of people employed as "SREs" or "production engineers" is actually far, far higher (at least an order of magnitude) than in the days before cloud became a thing. There are simply far more apps / companies / businesses / etc. who use cloud hosting than there ever were doing on-prem work.
I don’t think we would need less engineers… the work to be done will increase instead. Example: now it takes 10 engineers to release a product in 10 months without AI. With AI it takes lets say 1 engineer to release the same product in 1 month. What’s the company gonna do now? Release 10 products in 10 months without AI 10 engineers (each using AI).
It’s an exaggeration I know, but you get the point.
> What’s the company gonna do now? Release 10 products in 10 months without AI 10 engineers (each using AI).
Software is often not the bottleneck. If instead of 10 engineers you just need the one, the company will shed headcount it doesn't need. This might mean, for example, that instead of 10 developers and a software testing engineer, now a team changes to perhaps add testers while firing half of the developers.
> I don't actually enjoy it, i generally find it difficult to use as i have more trouble explaining what i want than actually just doing it.
This is my problem I run into quite frequently. I have more trouble trying to explain computing or architectural concepts in natural language to the AI than I do just coding the damn thing in the first place. There are many reasons we don't program in natural language, and this is one of them.
I've never found natural language tools easier to use, in any iteration of them, and so I get no joy out of prompting AI. Outside of the increasingly excellent autocomplete, I find it actually slows me down to try and prompt "correctly."
A bit extreme on my end, but I've got the spare hardware for it - when I get into a rut I change operating systems, so I'm bouncing back and forth between macOS and Windows or Linux.
I'm adept at using both but the change adds just enough friction and visual differences to spark creativity, or a little productivity boost.
