4 ms·
AI will take our jobs as soon as the suits learn how to precisely, accurately, and consistently express their needs in a backwards compatible fashion that doesn
by Swizec 2y ago
AI will take our jobs as soon as the suits learn how to precisely, accurately, and consistently express their needs in a backwards compatible fashion that doesn’t break existing customers.
That is to say never.
Our jobs will change. We might look more like product managers than code artisans. Or like lead engineers guiding mentoring and nudging robots to build the right thing.
But I suspect AI will take about as many engineering jobs as spreadsheets did. More people will be writing code and automating their tasks. When the spaghetti starts to break and becomes a bottleneck, we can come take over and turn it into a scalable engineering product. Perhaps with the help of our own robots doing the boring stuff.
- gigatexal 2y agoYeah … instead of fighting to stay mid-level it’s probably better to just skill up as best as possible. Even without AI the competition from fellow job applicants, overseas talent, etc., would mean we all have to get more productive and more skilled. But I’m looking to get off the rat race / wheel of futility and looking at things like consulting to augment and maybe replace my job. The autonomy and the flexibility and being my own boss so to speak is what I envy.
- scarface_74 2y agoAs long as by “consulting” you mean actual strategic consulting and not “staff augmentation”
- gigatexal 2y agoIf it’s work that I can set the hourly or project rate on I’ll take it. I mean I don’t ask or judge if the work is offered. But I guess I will find out if I am inheriting a half baked project suddenly given to me because all the wage workers were fired.
- scarface_74 2y agoThe difference is that staff augmentation consulting inherits the same issues as being a mid level ticket taker - you still just a commodity developer competing with other commodity developers from all over the world who are willing to work for a lot cheaper than you would be.
- s__s 2y ago> precisely, accurately, and consistently express their needs in a backwards compatible fashion that doesn't break existing customers. A theoretical “AI dev” will be able to gather these requirements through conversation no problem. The same way a human dev would. In fact it will probably do a better job. I really don’t think this is some special skill that protects developers from automation. The industry is about to change drastically. I don’t foresee software engineers going extinct, but there will most definitely be a lot fewer of them.
- Swizec 2y ago> A theoretical “AI dev” will be able to gather these requirements through conversation no problem Maybe! So far what I’ve seen are AI devs that are too afraid to say ”No you’re wrong this will never work” and can’t ask those awkward questions like ”Ok A sounds great, but you already promised to customer B that not-A will always be true. What do we do about that?” It is very important to have a working mental model of the system to do requirements gathering effectively. AI struggles mightily in that area.
- jf22 2y agoBut all you have to do is tell the AI your mental model and it remembers. And it will remember all the times some suit promised customer zyx four years ago this feature would be ready, and it remembers the insights the old PM had before they left, and it can read the four bug tickets related about a feature that describes conflicting behaviors...
- s__s 2y agoOut of the box sure. An agent set up specifically for this task with your code and internal docs is a whole different story. And LLMs aren’t afraid to say “you’re wrong”, they’ve just been configured to be agreeable by default.
- scarface_74 2y agoThere is so much that goes into gathering requirements for any large implementation that is not just about asking the requirements. There is the entire management and navigation of organizational politics and priorities, getting to the bottom of XYProblems, users not really knowing what they want and being able to help them get there, etc.
- scarface_74 2y ago> Our jobs will change. We might look more like product managers than code artisans. Or like lead engineers guiding mentoring and nudging robots to build the right thing. This is why I repeatedly tell software engineers not to be “ticket takers”. If your job is just pulling well defined stories off the board where the business requirement is already known - which is considered mid level behavior at every tech company where I have seen leveling guidelines - your job may be in danger by AI. But it is definitely in danger of being outsourced to cheaper labor and you’re just commodity and will find it hard to stand out against thousands of other commodities.
- godelski 2y agoAny employee's job is not to follow instructions, rather it is to do the job required to accomplish the company's goals. These are not always aligned. You know more than your manager about certain things and vice versa. You have to interpret. You have to use your expertise. It's easy to do work while creating more work for others. Move fast and break things works when learning but you don't go around breaking everything in the office either. Your expertise is not being glue between stack overflow and your codebase, your expertise is to understand the picture, limitations, failures, knowing there are different types of glutes, tapes, and fasteners. Your experience is seeing failures others don't, the cracks in the system. There's an old joke. There's two types of 10x developers 1) those like Knuth 2) those that complete 10 the number of jira tickets The former will prevent 100x tickets from ever being created, while the latter will be the cause (Yeah jokes aren't perfect. You don't need to nitpick and but actually. You can interpret )
- scarface_74 2y agoMy day job is a “staff” software architect working at a third party AWS cloud consulting company (coming from working at AWS directly doing the same thing) I am not bragging - I’m just old. I have “expertise” at some level or the other with: 1. Discovery, requirements gathering, creating project plans, etc - 2. project management (not great. But I’m good enough) 3. Tech lead for a software development project or a cloud architecture “DevOps” project 4. Your standard “senior” hands on enterprise software developer. 5. Every database type imaginable. 6. A “cloud engineer”. I can go from an empty AWS account to a completely “Well Architected” infrastructure using IaC and creating pipelines While I can do any of those, as a hands on keyboard person, I can only do 40 hours worth of work and I could never complete a moderately complex project that required me to do all six in an acceptable time period. When doing any of that work, I’m operating at most 2x the average person and that’s being generous. My value add, is that a company can throw me on a conference call or tell me to hop on a plane and deal directly with the client along with sales to close a deal and know I’m not going to embarrass them. On the other end, by being able to lead and coordinate between the customer, sales, and the hand on engineers , I can hopefully get a project across the finish line on time, on budget and that meets requirements.