Article summary
Learning the Software Development Lifecycle (SDLC) has never been easier.
When I say “learning,” I mean good old-fashioned reading the docs, trying something, failing, trying again, probably failing once more, and finally succeeding. Whatever part of the lifecycle you want to understand still needs that attention.
The traditional parts of the SDLC are planning, requirements gathering, design, implementation, testing, deployment, and maintenance.
Time Budgeting
Before agents, implementation took up most of the time I set aside for side projects. Agentic development has shrunk the implementation phase and made it possible to spend more time practicing the other phases of the SDLC.
I have countless side projects where spending less time writing code would have left more time to design better, iterate, test, and actually release them. Now I have enough time left over to care about the parts I used to skip on side projects.
The New Cool Factor
The feeling of “Whoa, I made this” is so much harder to come by when using agents. Now that feeling comes more from finishing the whole project than from getting one feature working.
Seeing smaller features work is cool, sure. I still decided to make them, but all I normally did was write a prompt, then review and fix whatever bugs the agent left behind.
That has made the other phases of the SDLC more interesting to me on greenfield projects. Deciding how the project should be structured, getting it deployed, setting up the pipelines, and eventually having somebody else use it all come close to the old feeling of having built something.
Creating Your Own Opportunities
At work, you don’t get to pick which parts of the SDLC you get to practice. The project decides that for you.
A junior developer can spend years working on mature applications without ever getting to plan a greenfield project, choose an architecture, set up a deployment pipeline, or figure out how a project should be maintained after release. Those are useful skills, but whether you get to practice them at work depends heavily on what your team is building.
Side projects let you create those opportunities yourself. If I want to practice deploying an application, I don’t need to spend most of my available time building the application first. The implementation only needs to be good enough to give me something real to deploy. Agents can get me to the part of development I actually want reps in faster.
Last fall I wanted to get better at CI/CD (Continuous Integration and Continuous Delivery or Deployment). Setting up one pipeline taught me something, but setting up pipelines across several small projects and seeing what broke each time gave me reps. The first time through, I was mostly figuring out where everything lived. By the third or fourth project, I was making actual choices instead of following steps. Agents make those reps way cheaper. I can spend less time spinning up new apps and more time getting practical experience.
Conclusion
Whatever you want to understand about the lifecycle is where you should spend your time. “Set up CI/CD, make no mistakes” is not much of an exercise.
Let the agents handle the setup needed to reach that step. Then read the docs, articles, or books on the subject and work through that phase yourself. Agents can still help, but keep your learning goal in mind when deciding what to hand over.
The reps only help if you can tell whether you’re getting better, so get feedback from someone with more experience in that part of the lifecycle.