I don't mean this as a snarky jab. It's coming for anything software. I've used AI to accomplish front end development and reverse engineer proprietary USB hardware dongles in C, then rewriting the C into Rust to get easy desktop GUIs around it. Backend APIs, systems programming, embedded programming, they all seem equally threatened it's just a matter of time. Front end is easy to see in the AI web front ends but everything else is still easy pickings.
You are describing the toy projects that had us all amazed end of last year. Large, maintainable software that can serve paying customers is in a completely different galaxy.
> I've used AI to accomplish front end development and reverse engineer proprietary USB hardware dongles in C, then rewriting the C into Rust to get easy desktop GUIs around it. Backend
That is not hard. It’s just tedious and very slow to do manually. The hard part would be about designing a usb dongle and ensuring that the associated software has good UX. The reason you don’t see kernel devs REing devices is not because it’s impossible or that it requires expert knowledge. It’s because it’s like counting sands on the beach.
Whether something is tedious depends on the person and situation. If you're already an expert, you may find a lot of work that goes into your 4th USB device (especially if it's based on yet another chip and bespoke SDK) quite tedious, since lot of it is based on standard requirements/designs that you can't change.
You may also find re-ing stuff not tedious, due to what may be motivating you.
In any case, any work will have some things you just know how to do, or what to do, but previously (before LLM agents) no easy way to plow through them without pressing a lot of keyboard keys over long period of time.
There's rather a big difference between reverse engineering already working code and forward(?) engineering working code from nothing so that confidence seems misplaced.
As a manager of a full stack team, we've found AI falls short a lot more on front end. It has its weak points on both front and back, but the problems with backend are quite easy to feed back into it -- needs more performance, needs to pass this security audit, needs to deal with xyz system. The problems with frontend are more like this is ugly, it's clunky to use, people don't like it. People without years of frontend experience tend to lack the vocabulary required to get AI to fix it, period, and it ends up going around in loops.
It is irrelevant that complex frontend would be easy for AI or not. To me 1) how many unique complex frontends are needed out of total frontends that millions of sites out there need. 2) Will there be increase in need of such frontend engineers so other displaced folks can land a job there.
I think it will be far fewer to have any positive impact on IT engineers' overall job prospects.
But that's equally true for any type of system. Frontend isn't inherently easier than other systems, so i was just wondering why you singled it out. To me AI just seems better at backends and database design
OK, my examples seemed like biased against frontend which was not the intention.
The thrust was overall job prospects for people in software field. It is not that frontend is easy but it is definitely easy to get into. Considering there are far more frontend developers then say C++ system engineers or database designers so in sheer numbers they will be affect more.
Ah okay that's fair. In my country boot camps aren't a thing so frontend devs are rare and good frontend devs even more, so I think it depends on where in the world you are. We got an abundance of java devs here that i fear more for
If you spend 95% of your time on that stuff, you better be working on like critical infrastructure where nothing can go wrong, otherwise you are in an incredibly dysfunctional company.
I agree it would be absurd for it to take 95% of your time.
I have, however, seen that it takes a lot more time than one would think.
I did some contracting work for a severely dysfunctional meeting heavy organization and it was about 2 hours of meetings for every hour of real technical work!
Even when it’s not dysfunctional, you spend a lot of time on communication and reading stuff other people wrote (including code). It’s very rare to work in isolation.
I guess it depends on what you feel coding is. To me it's the architecture planning and reading other people code, not just writing code. If we say it's just typing, then 95% is not absurd no
> it depends on what you feel coding is. To me it's the architecture planning and reading other people code, not just writing code
And that would be where we disagree. I don’t read code to look at code. When I’m reading code, I’m looking for the contracts to follow when interacting with a system. It would be nice if it were documented, but more often than not you have to rely on code.
It’s very rare that I plan with a technical mindset. Yes I use the jargon, but it’s all about the business needs. Which again create contracts.
Same with writing code. Code is like English for me. If I don’t have a clear idea on what to write, I stop and do research (or ask someone). But when I do, it’s as straightforward as writing a sentence.
Huh? So you you don't research if something is technically feasible before you promise your stakeholders a delivery time/ price estimate?
We all do the same stuff, the disagreement would just be what you feel coding is and if you think technical work is the same thing or a superset. If you as software dev aren't hands on with planning or working more than 5% of your time, you are basically a PO with a programing hobby
> So you you don't research if something is technically feasible before you promise your stakeholders a delivery time/ price estimate
I believe 99% of requests are not about what’s technically feasible. And the rare time I encountered one of those, my answer has mostly been “you don’t have enough resources to try solving that problem”.
If you know your fundamentals well, very often you will find the same common blocks everywhere. People much more smarter than me has solved a lot of fundamental issues and it’s rare that I see a business request that doesn’t reuse the same familiar stuff.
That’s why coding is mostly boring. You follow the same pattern again and again. But what dictates the flows are the business parameters. And that’s why most senior spend so much time gathering good requirements. Because the code is straightforward after that.
Ah yes agreed, if it's more than 90% it just signals to me that a developers skills are probably being wasted too much on business/coordination stuff.
But i guess if we mean actual time tapping your keyboard making code, then it's true some days for senior+ devs, but definitely not technical work overall.
I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
