"If you are looking for that one trick that lets you get ahead and jumpstart your career, my advice to you is: Don’t choose the path of least resistance. When training a muscle, you only get stronger with resistance. The same is true for learning any new skill. It is when you struggle with a specific problem or concept that you tend to remember."
As with anything, there's also too much of a good thing though.
In my own career I switched role to get more time on a area where I felt I needed more growth an practice. Turns out I never got really very good at it, and basically was just in a role I wasn't great at for 6 years. It was miserable. My lesson is "if you know you are bad at something, don't make it load-bearer in your life or career".
We have hard evidence of it becoming easier every damn day. AI is taking these jobs. The models aren't perfect, but the speed tradeoff is so massive that you really can't say it's "hard" to build anything anymore. Nobody is lying.
Edit: What I mean by this is there may be some circumstantial evidence (less hiring for juniors, more AI companies getting VC funding). We currently have no _hard_ evidence that programming has had a substantial speed increase/deskilling from LLMs yet. Any actual __science__ on this has yet to show this. But please, if you have _hard_ evidence on this topic I would love to see it.
If you think of building software as just writing the code then sure AI makes things a lot easier. But if software engineering also includes security, setting up and maintaining infrastructure, choosing the right tradeoffs, understanding how to deal with evolving requirements without ballooning code complexity, etc., then AI struggles with that at the moment.
The newbie prototype was never all that hard. You could, in my day, have a lot of fun that first week with dreamweaver, Visual Basic, or cargo cutting HTML.
There’s nothing wrong with this.
But to get much further than that ceiling you probably needed to crack a book.
Perhaps this is a bit OT, since the article focuses more on self-development ("When training a muscle, you only get stronger with resistance"), but I wonder about the subtitle:
> Every week there seems to be a new tool that promises to let anyone build applications 10x faster. The promise is always the same and so is the outcome.
Is the second sentence true? Regardless of AI, I think that programming (game development, web development, maybe app development) is easier than ever? Compare modern languages like Go & Rust to C & C++, simply for their ease-of-compilation and execution. Compare modern C# to early C#, or modern Java to early Java, even.
I'd like to think that our tools have made things easier, even if our software has gotten commensurately more complicated. If they haven't, what's missing? How can we build better tools for ourselves?
Anything (software or physical things) that is fast, easy, and cheap to build; will never be a financial success for a single company. The minute you get some market traction, your competitors will come in and take away all your customers.
Something that's been on my mind recently - what if gen AI coding tools are ultimately attention casinos in the same way social media is? You burn through tons of tokens and you pay per token, it feels productive and engaging, but ultimately the more you try and fail, the more money the vendor makes. Their expressed (though perhaps not stated) economic goal may be to keep you in the "goldilocks zone" of making enough progress to not give up, but not so much progress that you 1-shot to the end state without issues.
I'm not saying that they can actually do that per sé; switching costs are so low that if you are doing worse than an existing competitor, you'd lose that volume. Nor am I saying they are deliberately bilking folks -- I think it would be hard to do that without folks cottoning on.
But, I did see an interesting thread on Twitter that had me pondering [1]. Basically, Claude Code experimented with RAG approaches over the simple iterative grep that they now use. The RAG approach was brittle and hard to get right in their words, and just brute forcing it with grep was easier to use effectively. But Cursor took the other approach to make semantic searching work for them, which made me wonder about the intrinsic token economics for both firms. Cursor is incentivized to minimize token usage to increase spread from their fixed seat pricing. But for Claude, iterative grep bloating token usage doesn't harm them and in fact increases gross tokens purchased, so there is no incentive to find a better approach.
I am sure there are many instances of this out there, but it does make me inclined to wonder if it will be economic incentives rather than technical limitations that eventually put an upper limit on closed weight LLM vendors like OpenAI and Claude. Too early to tell for now, IMO.
> The problem is that while these tools can help you build a simple prototype incredibly quickly, when it comes to building functional applications they are much more limited
As someone with 0 (zero) swift skills and who has built a very well functioning iOS app purely with AI, I disagree.
AI made me infinitly faster because without it I wouldn‘t even have tried to build it.
And yes, I know the limits and security concerns and understand enough to be effective with AI.
You can build functioning applications just fine.
It‘s complexity and novel problems where AI _might_ struggle, but not every software is complex or novel.
true. I've built a simple app that solved the annoying problem usually in that app-space of giving/typing time and date.
after years and years, people still pay for it, which im very grateful.
i even saw many M$ companies build their products yet lacked the simple mind to ease the user ecperience with non-default date and time selector..
Am I missing something or is the actual point of the article just "don't start learning programming by using AI"? The title seems very different from the content.
This article includes a graph with a negative slope, claiming that AI tools are useful for beginners, but less and less useful the more coding expertise you develop.
That doesn't match my experience. I think AI tools have their own skill curve, independent of the skill curve of "reading/writing good code." If you figure out how to use the AI tools well, you'll get even more value out of them with expertise.
Use AI to solve problems you know how to solve, not problems that are beyond your understanding. (In that case, use the AI to increase your understanding instead.)
Use the very newest/best LLM models. Make the AI use automated tests (preferring languages with strict type checks). Give it access to logs. Manage context tokens effectively (they all get dumber the more tokens in context). Write the right stuff and not the wrong stuff in AGENTS.md.
I only realize how spot on the muscle training analogy is. In the modern world, very few people are hired for their muscles alone. Actually building muscle costs money for the absolute majority.
One of my all-time favorite quotes is from Zen Mind, Beginner's Mind and it goes: “In the beginner’s mind there are many possibilities, but in the expert’s there are few.”
There's such a wide divergence of experience with these tools. Often times people will say that anyone finding incredible value in them must not be very good. Or that they fall down when you get deep enough into a project.
I think the reality is that to really understand these tools, you need to open your mind to a different way of working than we've all become accustomed to. I say this as someone who's made a lot of software, for a long time now. (Quite successfully too!)
In someways, while the ladder may be getting pulled up on Junior developers, I think they're also poised to be able to really utilize these tools in a way that those of us with older, more rigid ways of thinking about software development might miss.
This reminds of talking to my nephew at Thanksgiving years ago. He was studying for an exam after the holidays and I was looking at his screen open to a Google Doc which looked like his study notes except - they were being edited as I was watching - by someone else. I asked about it and he goes “we have a single Google Doc where all students collaborate on the study notes.” My mind was blown, I was also using Google Docs but not in a millions years would it cross my mind its utility for such a thing he and his classmates were using it for. Can’t wait to see what new blood “Juniors” brings to the table!
Over the last 25 years of building commercial software, but being a programming enthusiast since I was 15 years old, I came to the conclusion that self-improvement (in the sense of gaining real expertise in a field, building a philosophy of things, and doing the right things) is in direct opposition to creating "value" in the corporate/commercial sense of today.
Using AI/LLMs, you perhaps will create more commercial value for yourself or your employer, but it will not make you a better learner, developer, creator, or person. Going back to the electronic calculator analogy that people like to refer to these days when discussing AI, I also now think that, yes, electronic calculators actually made us worse with being able to use our brains for complex things, which is the thing that I value more than creating profits for some faceless corporation that happens to be my employer at the moment.
I was talking about this with someone today, that before perhaps there is an exactness you expect. But actually, what really matters is "good enough." And if AI written code takes you to "good enough" according to whatever metric you've set, then what exactly is the problem? Because a lot of the technical part of the job is taking X data, doing f(x) transformation to that data, and thus Y is born and handed to the next step. So if it passes whatever metric you have set to make sure that going from X to Y handles Z% of the problem space, and doesn't create downstream issues (probably this should be part of your metric), then you have done your job. And yes, of course sometimes the job will require you writing the code yourself because that level if precision is necessary. But why should we consider that always to be the case? And thus, actually, there are probably new programming languages and paradigms to consider that we haven't thought of yet that makes this kind of problem solving more efficient. Because right now we are not super effective at juggling both the human and the machine's problem space context. Except some experts who say they can orchestrate tens of agents all at once doing whatever. I dunno. I think right now is exciting and not hand wringing. A computer is meant to help you think. Why shouldn't new computational tools bring excitement?
LLMs have clearly accelerated development for the most skilled developers.
Particularly when the human acts as the router/architect.
However, I've found Claude Code and Co only really work well for bootstrapping projects.
If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use.
It will probably change once the approach to large scale design gets more formalized and structured.
We ultimately need optimized DSLs and aggressive use of stateless sub-modules/abstractions that can be implemented in isolation to minimize the amount of context required for any one LLM invocation.
Yes, AI will one shot crappy static sites. And you can vibe code up to some level of complexity before it falls apart or slows dramatically.
> We ultimately need optimized DSLs and aggressive use of stateless sub-modules/abstractions that can be implemented in isolation to minimize the amount of context required for any one LLM invocation
Wait till you find out about programming languages and libraries!
> It will probably change once the approach to large scale design gets more formalized and structured
This idea has played out many times over the course of programming history. Unfortunately, reality doesn’t mesh with our attempts to generalize.
What I've found is that AI can be alright at creating a Proof of Concept for an app idea, and it's great as a Super Auto-complete, but anything with a modicum of complexity, it simply can't handle.
When your code is hundreds of thousands of lines, asking an agent to fix a bug or implement a feature based on a description of the behavior just doesn't work. The AI doesn't work on call graphs, it basically just greps for strings it thinks might be relevant to find things. If you know exactly where the bug lies, it can usually find it with context given to it, but at that point, you're just as good fixing the bug yourself rather than having the AI do it.
The problem is that you have non-coders creating a PoC, then screaming from the rooftops how amazing AI is and showing off what it's done, but then they go quiet as the realization sets in that they can't get the AI to flesh it out into a viable product. Alternatively, they DO create a product that people start paying to use, and then they get hacked because the code is horribly insecure and hard-codes API keys.
The most interesting thing for me is that I am sure it does.
I have been coding for 20+ years and I have used AI agents for coding a lot, especially for the last month and a half. I can't say for sure they make me faster.They definitely do for some tasks, but over all? I can solve some tasks really quickly, but at the same time my understanding of the code is not as good as it was before. I am much less confident that is is correct.
LLMs clearly make junior and mid level engineers faster, but it is much harder to say for Senior.
There is a point in there, long-range analysis and debugging without AI
is much harder, AI spots lots of non-obvious stuff very fast.
If we consider "spotting non-obvious flaws" a skill, this will
atrophy as beginners will learn to use AI to scan code for
flaws,it is effective but doesn't teach anything, reading long blocks
of code and mentally simulating it is a incredibly valuable skill
and it will find stuff AI misses(something that is too complex, e.g. nested/recursive control flow,async
and co-routines/threads interacting,etc), AI goes for obvious stuff first and
has to be manually pointed to "identify flaws, focusing on X".
> All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.
AI, the silver bullet. We just never learn, do we?
> With no-code tools you often reach a hard limit where the tool simply does not make sense to use anymore.
No-code is the same trend that has abstracted out all the generic stuff into infrastructure layers, letting the developers to focus on Lambda functions, while everything in the lower levels is config-driven. This was happening all the time, pushing the developer to easier higher layers and absorbing all complexity and algorithmic work into config-driven layers.
Runtime cost of a Lambda function might far exceed that of a fully hand-coded application hosted on your local server. But there could be other factors to consider.
Same with AI. You get a jump-start with full speed, and then you can take the wheel.
Software is the hardest thing on planet earth. That's why there's this concept of bootcamps. No other profession has this concept of "bootcamps".
Building a plane is easier than building software. That's why they don't have bootcamps for building planes or becoming a rocket engineer. Building rockets or planes as an engineer is a breeze so there's no point in making a bootcamp.
That's the awesome thing about being a swe, it's so hard that it's beyond getting a university degree, beyond requiring higher math to learn. Basically the only way to digest the concept of software is to look at these "tutorials" on the internet or have AI vibe code the whole thing (which shows how incredibly hard it is, just ask chatGPT).
My friend became a rocket engineer and he had to learn calculus, physics and all that easy stuff which university just transferred into his brain in a snap. He didn't have to go through an internet tutorial or bootcamp.
I have to strongly disagree with that. I provably never was as productive as when I used REALbasic, which was a classical RAD tool. I sold the software made with it successfully for quite a while.
As most people here probably know, it's now called Xojo and in my opinion both somewhat outdated and expensive. So I'm not recommending it, but credit to were it's due and it certainly was due for early versions of REALbasic when it was still affordable shareware.
The problem with all RAD tools seems to be that they eventually morph into expensive corporate tools no matter what their origins were. I don't know any cross-platform exception (I don't count Purebasic as RAD and it's also not structured).
As for AI, it seems to be just the same. The right AI tool accelerates the easy parts so you have more time for the hard parts. Another thing that bothers me a lot when alleged "professionals" are arguing against everyday computing for everyone. They're accelerating the death of general computing platforms and in the end no one will benefit from that.
strongly disagree with this article. I think using the tools can actually directly lead to a junior engineer getting closer to a senior engineer. Telling junior engineers that they have to get better at typing out code in order to be better engineers misses what actually makes someone a better engineer.
It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture. the combination of these two makes you a better problem solver. talking to other people helps you figure out your blindspots and forces you to reduce complex ideas down to their most essential parts. the loop of solving a problem and then seeing how well the solution worked gives you an instinct for what works and what doesn't work for any given problem. So how do agents make you better at these two things?
If you are better at explaining what you want, you can get the agents to do what you want a lot better. So you'd end up being more productive. I've seen junior developers that were pretty good problem solvers improve their ability to communicate technical ideas after using agents.
Senior engineers develop instincts for issues down the road. So when they begin any project, they'll take this into account and work by thinking through this. They can get the agents to build towards a clean architecture from the get go such that issues are easily traceable and debuggable. Junior developers get better at architecture by using agents because they can quickly churn through candidate solutions. this helps them more rapidly learn the strengths and weaknesses of different architectures.
> It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture.
Uhhh… also skills and abilities? You won’t develop either of those by repeatedly asking an AI to solve problems for you.
^ Everything App for Personal use that I'm thinking about making public in some way
~50k loc with ~400 files. Docker, postgres, react + fastify
I'd say between 15 and 20 hours of vibe coding
- Tasks, Goals, Habits
- Calendar showing all of the above with two way google sync
- Household sharing of markdown notes, goals and more
- Financial projections, spending, earning, recurring transactions and more
- Meal tracking with pics, last eaten, star rating and more
- Gantt chart for goals
- Dashboard for at a glance view
- PWA for android with layout optimizations
- Dark mode
... and more
Could've I done it in the last 5 years? Yes. It would've taken 3-4 months if not more though.
Now we could talk 24/7 about whether it's clean code, super maintainable, etc. etc. The code written by hand wouldn't be either if it'd be me just doing a hobby project.
Shipping is rather straightforward as well thanks to LLM's. They hold your hand most of the way. Being a techie makes this much, much easier...
I think developers are cooked one way or another. Won't take long now.
Same question asked a year ago was dramatically different. AI were helpful to some extent but couldn't code up basic things.
years ago I watched a very senior engineer refuse to use an IDE debugger because “real understanding means doing it in your head.” He was brilliant - and also spent two days chasing a bug a junior fixed in 10 minutes by setting a breakpoint. The junior didn’t understand more; he just had a better tool for that moment.
Tools don’t make you wiser or lazier by default — they amplify whatever habits you already have. If you’re using them to avoid thinking, that shows. If you’re using them to explore faster, that shows too.
Beginner’s mind isn’t about ignorance; it’s about being willing to try leverage where it exists.
39 comments
[ 3.1 ms ] story [ 56.0 ms ] threadPretty nice description.
In my own career I switched role to get more time on a area where I felt I needed more growth an practice. Turns out I never got really very good at it, and basically was just in a role I wasn't great at for 6 years. It was miserable. My lesson is "if you know you are bad at something, don't make it load-bearer in your life or career".
Edit: What I mean by this is there may be some circumstantial evidence (less hiring for juniors, more AI companies getting VC funding). We currently have no _hard_ evidence that programming has had a substantial speed increase/deskilling from LLMs yet. Any actual __science__ on this has yet to show this. But please, if you have _hard_ evidence on this topic I would love to see it.
If you only care about a single metric you can convince yourself to make all kinds of bad decisions.
> Nobody is lying.
Nobody is being honest either. That happens all the time.
The newbie prototype was never all that hard. You could, in my day, have a lot of fun that first week with dreamweaver, Visual Basic, or cargo cutting HTML.
There’s nothing wrong with this.
But to get much further than that ceiling you probably needed to crack a book.
> Every week there seems to be a new tool that promises to let anyone build applications 10x faster. The promise is always the same and so is the outcome.
Is the second sentence true? Regardless of AI, I think that programming (game development, web development, maybe app development) is easier than ever? Compare modern languages like Go & Rust to C & C++, simply for their ease-of-compilation and execution. Compare modern C# to early C#, or modern Java to early Java, even.
I'd like to think that our tools have made things easier, even if our software has gotten commensurately more complicated. If they haven't, what's missing? How can we build better tools for ourselves?
I'm not saying that they can actually do that per sé; switching costs are so low that if you are doing worse than an existing competitor, you'd lose that volume. Nor am I saying they are deliberately bilking folks -- I think it would be hard to do that without folks cottoning on.
But, I did see an interesting thread on Twitter that had me pondering [1]. Basically, Claude Code experimented with RAG approaches over the simple iterative grep that they now use. The RAG approach was brittle and hard to get right in their words, and just brute forcing it with grep was easier to use effectively. But Cursor took the other approach to make semantic searching work for them, which made me wonder about the intrinsic token economics for both firms. Cursor is incentivized to minimize token usage to increase spread from their fixed seat pricing. But for Claude, iterative grep bloating token usage doesn't harm them and in fact increases gross tokens purchased, so there is no incentive to find a better approach.
I am sure there are many instances of this out there, but it does make me inclined to wonder if it will be economic incentives rather than technical limitations that eventually put an upper limit on closed weight LLM vendors like OpenAI and Claude. Too early to tell for now, IMO.
[1] https://x.com/antoine_chaffin/status/2018069651532787936
As someone with 0 (zero) swift skills and who has built a very well functioning iOS app purely with AI, I disagree.
AI made me infinitly faster because without it I wouldn‘t even have tried to build it.
And yes, I know the limits and security concerns and understand enough to be effective with AI.
You can build functioning applications just fine.
It‘s complexity and novel problems where AI _might_ struggle, but not every software is complex or novel.
This is so frustratingly common.
That doesn't match my experience. I think AI tools have their own skill curve, independent of the skill curve of "reading/writing good code." If you figure out how to use the AI tools well, you'll get even more value out of them with expertise.
Use AI to solve problems you know how to solve, not problems that are beyond your understanding. (In that case, use the AI to increase your understanding instead.)
Use the very newest/best LLM models. Make the AI use automated tests (preferring languages with strict type checks). Give it access to logs. Manage context tokens effectively (they all get dumber the more tokens in context). Write the right stuff and not the wrong stuff in AGENTS.md.
This is how I see hand-building software goes.
There's such a wide divergence of experience with these tools. Often times people will say that anyone finding incredible value in them must not be very good. Or that they fall down when you get deep enough into a project.
I think the reality is that to really understand these tools, you need to open your mind to a different way of working than we've all become accustomed to. I say this as someone who's made a lot of software, for a long time now. (Quite successfully too!)
In someways, while the ladder may be getting pulled up on Junior developers, I think they're also poised to be able to really utilize these tools in a way that those of us with older, more rigid ways of thinking about software development might miss.
Using AI/LLMs, you perhaps will create more commercial value for yourself or your employer, but it will not make you a better learner, developer, creator, or person. Going back to the electronic calculator analogy that people like to refer to these days when discussing AI, I also now think that, yes, electronic calculators actually made us worse with being able to use our brains for complex things, which is the thing that I value more than creating profits for some faceless corporation that happens to be my employer at the moment.
3 years ago the idea of measuring productivity in lines of code would have been ridiculous. After AI, it is the norm.
Particularly when the human acts as the router/architect.
However, I've found Claude Code and Co only really work well for bootstrapping projects.
If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use.
It will probably change once the approach to large scale design gets more formalized and structured.
We ultimately need optimized DSLs and aggressive use of stateless sub-modules/abstractions that can be implemented in isolation to minimize the amount of context required for any one LLM invocation.
Yes, AI will one shot crappy static sites. And you can vibe code up to some level of complexity before it falls apart or slows dramatically.
Wait till you find out about programming languages and libraries!
> It will probably change once the approach to large scale design gets more formalized and structured
This idea has played out many times over the course of programming history. Unfortunately, reality doesn’t mesh with our attempts to generalize.
What I've found is that AI can be alright at creating a Proof of Concept for an app idea, and it's great as a Super Auto-complete, but anything with a modicum of complexity, it simply can't handle.
When your code is hundreds of thousands of lines, asking an agent to fix a bug or implement a feature based on a description of the behavior just doesn't work. The AI doesn't work on call graphs, it basically just greps for strings it thinks might be relevant to find things. If you know exactly where the bug lies, it can usually find it with context given to it, but at that point, you're just as good fixing the bug yourself rather than having the AI do it.
The problem is that you have non-coders creating a PoC, then screaming from the rooftops how amazing AI is and showing off what it's done, but then they go quiet as the realization sets in that they can't get the AI to flesh it out into a viable product. Alternatively, they DO create a product that people start paying to use, and then they get hacked because the code is horribly insecure and hard-codes API keys.
Have they so clearly? What's the evidence?
I have been coding for 20+ years and I have used AI agents for coding a lot, especially for the last month and a half. I can't say for sure they make me faster.They definitely do for some tasks, but over all? I can solve some tasks really quickly, but at the same time my understanding of the code is not as good as it was before. I am much less confident that is is correct.
LLMs clearly make junior and mid level engineers faster, but it is much harder to say for Senior.
> All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.
AI, the silver bullet. We just never learn, do we?
No-code is the same trend that has abstracted out all the generic stuff into infrastructure layers, letting the developers to focus on Lambda functions, while everything in the lower levels is config-driven. This was happening all the time, pushing the developer to easier higher layers and absorbing all complexity and algorithmic work into config-driven layers.
Runtime cost of a Lambda function might far exceed that of a fully hand-coded application hosted on your local server. But there could be other factors to consider.
Same with AI. You get a jump-start with full speed, and then you can take the wheel.
Building a plane is easier than building software. That's why they don't have bootcamps for building planes or becoming a rocket engineer. Building rockets or planes as an engineer is a breeze so there's no point in making a bootcamp.
That's the awesome thing about being a swe, it's so hard that it's beyond getting a university degree, beyond requiring higher math to learn. Basically the only way to digest the concept of software is to look at these "tutorials" on the internet or have AI vibe code the whole thing (which shows how incredibly hard it is, just ask chatGPT).
My friend became a rocket engineer and he had to learn calculus, physics and all that easy stuff which university just transferred into his brain in a snap. He didn't have to go through an internet tutorial or bootcamp.
As most people here probably know, it's now called Xojo and in my opinion both somewhat outdated and expensive. So I'm not recommending it, but credit to were it's due and it certainly was due for early versions of REALbasic when it was still affordable shareware.
The problem with all RAD tools seems to be that they eventually morph into expensive corporate tools no matter what their origins were. I don't know any cross-platform exception (I don't count Purebasic as RAD and it's also not structured).
As for AI, it seems to be just the same. The right AI tool accelerates the easy parts so you have more time for the hard parts. Another thing that bothers me a lot when alleged "professionals" are arguing against everyday computing for everyone. They're accelerating the death of general computing platforms and in the end no one will benefit from that.
It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture. the combination of these two makes you a better problem solver. talking to other people helps you figure out your blindspots and forces you to reduce complex ideas down to their most essential parts. the loop of solving a problem and then seeing how well the solution worked gives you an instinct for what works and what doesn't work for any given problem. So how do agents make you better at these two things?
If you are better at explaining what you want, you can get the agents to do what you want a lot better. So you'd end up being more productive. I've seen junior developers that were pretty good problem solvers improve their ability to communicate technical ideas after using agents.
Senior engineers develop instincts for issues down the road. So when they begin any project, they'll take this into account and work by thinking through this. They can get the agents to build towards a clean architecture from the get go such that issues are easily traceable and debuggable. Junior developers get better at architecture by using agents because they can quickly churn through candidate solutions. this helps them more rapidly learn the strengths and weaknesses of different architectures.
Uhhh… also skills and abilities? You won’t develop either of those by repeatedly asking an AI to solve problems for you.
"Writing software is easy, changing it is hard."
^ Everything App for Personal use that I'm thinking about making public in some way
~50k loc with ~400 files. Docker, postgres, react + fastify I'd say between 15 and 20 hours of vibe coding
- Tasks, Goals, Habits
- Calendar showing all of the above with two way google sync
- Household sharing of markdown notes, goals and more
- Financial projections, spending, earning, recurring transactions and more
- Meal tracking with pics, last eaten, star rating and more
- Gantt chart for goals
- Dashboard for at a glance view
- PWA for android with layout optimizations
- Dark mode
... and more
Could've I done it in the last 5 years? Yes. It would've taken 3-4 months if not more though. Now we could talk 24/7 about whether it's clean code, super maintainable, etc. etc. The code written by hand wouldn't be either if it'd be me just doing a hobby project.
Shipping is rather straightforward as well thanks to LLM's. They hold your hand most of the way. Being a techie makes this much, much easier...
I think developers are cooked one way or another. Won't take long now. Same question asked a year ago was dramatically different. AI were helpful to some extent but couldn't code up basic things.
Tools don’t make you wiser or lazier by default — they amplify whatever habits you already have. If you’re using them to avoid thinking, that shows. If you’re using them to explore faster, that shows too.
Beginner’s mind isn’t about ignorance; it’s about being willing to try leverage where it exists.