The one reason I can't care about these kind of arguments is that you're describing the solution, not the problem. Based on my career (maybe shorter than yours), usually you put juniors on projects of low complexity and low impact while you play the mentor role. It's not about them being a productive worker or a menial helper, it's for them to train using practical projects. Your problems don't look like suitable projects unless you want them to train them in copy-pasta from the Internet.
Junior - everything is spelled out in excruciating detail, the what and the how. They are going to be slow, not know best practices, constantly bug other developers and you srs going to have to correct them a lot.
Mid level developer - little ambiguity on the business case or their role in it. They are really good coders in their domain. They have the experience to turn well defined business requirements into code. You don’t have to explain the “how” to them just the what. They should have the ability to break an assigned “epic” based on the business requirements to well defined stories and be a single responsible individual for that Epic maybe working with juniors depending on the deliverable or other mid level developers.
A senior developer works at a higher level of ambiguity and a larger scope, the business may know they want something. But neither the business or technical requirements are well defined. Think of a team lead.
Senior+ - more involved with strategy.
If I have to define everything in great detail anyway, why not just use AI? It can do it faster, cheaper, more correct and the iteration is faster. I would go as far as saying in my recent coding agent experience, a coding agent is realistically 100x faster than a junior developer since you have to give both of them well defined tasks.
My experience with Claude code and codex recently is that even the difference between a mid level developer and a coding agent is taste when it comes to user facing development, knowing funky action at a distance, and knowing the business, with a mid level developer you can assume shared context and history with an ability to learn.
So again, why do I need to hire a junior developer in the age of AI?
As an Entry Level Engineer, you’ll be expected to develop and maintain lower complexity components under the guidance and tutelage of more experienced team members.
That does not really contradict my point.
> If I have to define everything in great detail anyway, why not just use AI?
You don't have to define everything. And to do so is detrimental to their growth. If you're their mentor, you're supposed to give them problems, not recipes. And guidance may be as little as an hint or pointing them to some resource, not giving them the solution outright. The goal is not to get a problem solved (that's just a nice-to have), the goal is to nuture a future colleague.
Why should I hire a junior who doesn’t know the what or the how. Instead of hiring a mid level developer who could be an excellent developer who can turn business requirements into code and is more than likely better at certain things than I am since they live and breathe it everyday and can both do the work without supervision and can offer valuable advice and say something that might convince me that I didn’t think things clearly?
Reminding you that the difference above a mid level developer and a “senior”/“senior+” is scope and ambiguity not necessarily technical depth in one area.
What does a junior developer bring to the table that I should use my open req on?
> Why should I hire a junior who doesn’t know the what or the how.
I'm not saying you should. It's the business model that will answer that question. But the traditional wisdom was that juniors are not costly and have few obligations tying them down. And juniors don't stay junior.
And some may know the what and the how, at least technically. What they may lack may be just how to develop their skills further to be useful in a professional settings. It's easy to learn programming languages, tools, libraries and frameworks when you have a lot of free time. And they're not asking to be your protégés, you're just training them to be useful for your team.
> Codev isn’t an AI model. It’s not a coding assistant. It’s not a VS Code extension. It’s a set of CLI tools, protocols, and infrastructure that orchestrates existing AI coding tools (Claude Code, Gemini CLI, OpenAI’s Codex CLI) into a structured workflow.
Thanks for the clarification, I couldn't have guessed otherwise.
The value of computers since its inception was that it's capable of transforming data very, very fast and autonomously. But someone has to input that data from the real world or capture it using some device, and someone has to write the rules.
What happened is that we created a whole world of information and the rules has become very complex. Now we have multiple layers stacked vertically and multiple domains spread horizontally. At one time, ASCII was enough, now we have to deal with Unicode.
Software becoming worthless will mean that everyone has learned the rules of the systems we created and capable of creating systems with good enough quality. I'm not seeing that happens anytime soon.
Software is just means to an end. Data and data transformation is what people want. Software has sellable dollar value only because creating the software to do the data transformation has had real associated cost. I.e anyone who wanted a particular data transformation had to pay to get the software that does it.
When you drive down that cost you drive down the potential value of the software products. Remember that what is a cost to one party is revenue to the other party. Without revenue there cannot be profit and without revenue software has no dollar value.
If anyone can create "photoshop" with minimal cost and there are thousands of said "photoshop" apps what will be the retail sell value of those apps. Close to zero.
This same lifecycle already happened with games. Driving down the cost of producing games resulted in a proliferation of games that are mostly worthless that you can't even give away.
> Software is just means to an end. Data and data transformation is what people want. Software has sellable dollar value only because creating the software to do the data transformation has had real associated cost. I.e anyone who wanted a particular data transformation had to pay to get the software that does it.
I do agree with you on that point.
> If anyone can create "photoshop" with minimal cost and there are thousands of said "photoshop" apps what will be the retail sell value of those apps. Close to zero.
This is the point that I cannot agree with. Not anyone can create photoshop because of the amount of knowledge you need about the data and transformations that needs to be applied to get a specific result. And then make a coherent system around it. You can create isolated function just fine, just like a lot of people knows how to build a shed with planks and nails. But even when given all the materials and tools, only a few can build a skyscraper or a mansion.
That knowledge of how to create a coherent systems that does something well is the real cost of software. Producing code isn't it.
You're right and I agree with you to an extent. Also as of now the tools aren't quite intelligent enough for one to produce software of that complexity without having someone competent at the helm.
That being said what already exists was already enough to shutter the stock prices of many software companies precisely because the fear is that their clients will just re-create the software themselves instead of buying it from someone else.
I guess we'll see how this will pan out in the next few years.
> Yeah but a manager can do those things. You don't need an engineer for that.
Can they really? Engineering is about keeping the whole picture in mind so that you know which lever to push and which to not push for a certain goal. Trying until you're lucky can get you to that goal, but it's costly and not sustainable. So you need someone that can work out a model for experimentation in a less costly manner.
Judgment in this case is about deciding which path to direct the project, tradeoffs is being aware that there are other paths that are better in some aspects. And responsibility is acknowledging that a bad decision will bear a personal cost.
Everyone does the above in their own domain. But I don't think I've ever see a manager wanting to do it in the engineering domain. It's more about pushing the engineer to accept the responsibility, but denying them the power of judgment.
One of the good book about writing I read was William Zinsser's "On Writing Well". Striving for simplicity and avoiding clutter was the two first principles described in the book. AI writing feels more like ramblings than communication.
There's an art to it. Most human attempts, and every LLM attempt I've ever seen, are awful, sometimes bordering on unreadable, but, as you say, there are a relatively small number of authors who do it well. That doesn't mean that most people should do it.
I'm a French speaker and florid and elaborate writing is something I've grown up with. It can be difficult if you don't know the word or are not used to the style, but it's not boring. AI writing is just repetitive.
When I've used AI for proofreading the suggestions it makes to me is to cut a lot and shorten it. It also gives me examples, never with my voice or style though.
Where the hell do people go that they are away from power for 15 hours and are on the computer the whole time? Are they video editing while in the middle of a safari?
And besides, every time I see comments like this, all I can think is that they never have even tried to find a PC laptop that is small, fast and has good battery life. Believe it or not they exist.
Long running batteries would have been useful when I first was on safari in 2002. But last year I was on safari again, and at camp there was power and wifi in the tents. It actually kind of killed some of the romance.
I feel the same way with smartphones, everyone wants more battery. Ten years ago it might be difficult to find a place were you can charge your phone but now there are sockets everywhere.
I like tests, but I don't bother with TDD because it's so ceremonial. I design the API, or at least sketch it out (using a whiteboard or drafting some notes, and doing research). Then I iterate and refine. I only bother with tests once I can commit or when it's no longer viable to tests manually (edit-compile-run cycle). And a lot of time I follow the table pattern.
And as everyone who can abstract well knows: Ugly code that have staying power have a reason to be ugly. And the best will be annotated with HACK and NOTE comments. Anything else can be refactored and abstracted to a much better form. But that requires a sense of craftsmanship (to know better) and a time allowance for such activity.
The code for the machine to execute is opcodes realized by electric signals. But it's not a good tool to solve problems even when directly translated to assembly. All the other languages were invented for better human affordance and can map to assembly (and opcodes) with logical rules.
The last part is what matters. There's no such clear rules in LLMs behavior. Yes you can get to behave roughly like a rule, but there's no clear cut demarcation between what's in and what's not.
The usual person that believe in the trope is the one that wants something with short-term budget, but with long-term quality. Lot of engineers know the triangle of budget-scope-time. But a lot of managers want to have the cake and eat it too. When they ask to reduce time and the budget and the engineer ask what to reduce in the scope, they get all vague and shifty.
reply