I'm 15+ years in security and just this week I needed to hit a few domains, find a script tag that imports JS from a certain CDN, parse and make sense of it.
After 20 minutes of telling ChatGPT exactly what I needed and a couple of test runs and optimizations, I had the perfect tool. 10 years ago this would have been a half to full day project.
I had a meeting with an entry level security engineer and he asked if I need him to do the task, as we were both in the meeting where it was being discussed.
I didn't even think to ask him! It was quicker and easier to do it myself.
This was the type of project I had been assigned dozens of times during my first job.
I don't know what that means for the future of work but it's changing fast.
Scripts and unix pipe style work flows like this are going to be the easiest to automate. Even 5-6 years ago if you knew where to look for some cutting edge stuff, this was what they were experimenting with in automated code gen space and it was pretty good back then. The difference is you didn't do natural language prompts, you had to be able to ask for things in a very specific way.
It doesn't make up the bulk of development (though LLMs are eating low hanging fruit there too but its going to take a little longer) its a canary in the coalmine for how much this tech will cause some kind of disruption to people's jobs.
Whether it means that ultimately, it'll be like the adoption of the computer itself (an explosion of jobs relative to those who lost them due to the wide scale of computers) or not remains to be seen. It might open up higher forms of work and focusing on more thorny problems.
Why did you think you needed to hire a junior dev before even starting work on the application? I know estimation can be a difficult task but the typical "I'm moving so fast..." type experiences usually mean you didn't or don't understand your tooling or the scope.
Also how were you going to take on a junior dev and a new framework at the same time? Were you expecting them to know the framework?
As the saying goes though the last 20% takes 80% of the time.
Because the project was big enough to warrant more than one person. I have a whole team surrounding me to handle non-technical/non-development incidentals. Most companies would have had a lot more budgeted and would have pre-hired five devs. Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.
> Because the project was big enough to warrant more than one person.
But based on what, the scope? If you weren't familiar with the tech stack how would you gauge that? I understand people can conceptualize frameworks at a high-level.
> I have a whole team surrounding me to handle non-technical/non-development incidentals.
Are these the people finding the junior or (5) devs that would be needed. Do they have experience with the framework to know how to scope the project? The hiring of 1 - 5 developers in-house or even as contractors is a labor intensive process so I'm not really sure companies would have just done it based on an idea of an application. I can see where they might have hired early based on winning a contract but they probably under estimated the work if that was the case or padded the cost to account for ramp-up time.
> Most companies would have had a lot more budgeted and would have pre-hired five devs.
Maybe you haven't worked places that do spikes or just allow people to develop prototypes without entire scoping documents or hiring people. Also keep an eye on your worth here. If you are saving the company the cost involved in getting (5) more developers then you should be getting a bonus or have decent compensation. A lot people fall in this trap of "saving" the company money as if its their own, its not, and unless you are getting some of that savings you are diluting your current pay and working twice as hard.
> Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.
Yeah this is understood as the "mythicial man month" in terms of things slowing down. Adding the wrong head count is a planning and leadership issue. There is nothing stopping teams from being dynamic at a point but that depends on how long the application is going to be supported. Having (5) people now can spread out the working knowledge and workload enough that "no single" developer is holding up forward progress. If you are having to mentor people on the project or fix mistakes then they are the wrong people or wrong skillset for the team. A leader will be able to convey the issue to management and have people let go or replaced. People don't like to do this but there is no reason to keep a failed process going as we are all professionals. Alternatively people above you have accepted this as part of the application development process, it justifies their job, and are fine with it so getting the work done any faster is just a bonus to them.
Honestly it sounds like it wasn't a tool that is needed often, if it was you or someone else would have already written it. Or you don't regularly day-to-day program enough in javascript / python to do this quickly. There isn't anything wrong with that, as you mentioned, you have entry level security engineers that typically handle those tasks. Creating a tool goes fast when you know exactly what you want it to do and don't have to explain to another person all the requirements and pitfalls to avoid based on experience you might have in writing quick scripts. I don't know if this really changes anything.
After 20 minutes of telling ChatGPT exactly what I needed and a couple of test runs and optimizations, I had the perfect tool. 10 years ago this would have been a half to full day project.
I had a meeting with an entry level security engineer and he asked if I need him to do the task, as we were both in the meeting where it was being discussed.
I didn't even think to ask him! It was quicker and easier to do it myself.
This was the type of project I had been assigned dozens of times during my first job.
I don't know what that means for the future of work but it's changing fast.