Can AI write code? Yes.
AI coding tools can generate functions, explain unfamiliar code, suggest fixes, write tests and even work through larger development tasks. For someone learning to code, that makes the first steps into software development feel much easier.
But writing code and engineering software are not the same thing. A piece of code can work perfectly and still be the wrong solution. It might not scale. It might introduce a security risk. It might be hard for another developer to maintain. Or it might deliver the feature request while ignoring what the business actually needs.
This guide explains what software engineers really do, how the software development life cycle works, and which skills beginners should focus on if they want to build a career, not just write code.
What does a software engineer actually do?
A software engineer designs, builds, tests and maintains software systems. Beyond writing code, they clarify user and business requirements, learn how existing systems behave, make design trade-offs, plan for security and reliability, and monitor software after release so it keeps working for real users.
Before writing a single line of code, an engineer needs to understand the problem. That means asking questions like these:
- What does the user need?
- Why does this feature matter?
- What constraints does the business have?
- What does the existing system already do?
- What could go wrong if we introduce this change?
The answers shape the technical solution. Imagine a Kenyan online shop that wants to accept M-Pesa payments at checkout. The obvious task is to integrate Safaricom’s Daraja API. An engineer has much more to think about:
- What happens if the customer never enters their PIN, or the STK push times out?
- What if the payment callback never reaches the server?
- How do we stop a customer from being charged twice when they tap “Pay” again?
- What transaction data should we store, and how do we protect it?
- How will the new payment option affect the existing checkout flow?
The code is only one part of solving that problem. This is why the skills employers want in software engineers go beyond programming languages. Employers need people who can understand systems, investigate problems, communicate with teams and make sensible technical decisions.
Understanding the system you’re working with
Software rarely starts from a blank page. Most engineers work on systems with years of decisions behind them: older services, databases, third-party integrations, technical debt, and parts of the architecture nobody would design the same way today.
A developer joining that kind of project needs to understand how the system actually behaves, not just how it was meant to behave. That means reading existing code, checking documentation, looking at logs, mapping dependencies and talking to the people who know the system best.
An AI assistant can help here. It can explain a function or suggest where a piece of logic might live. But someone still needs to see the bigger picture. That’s why the skills a junior software engineer needs go beyond coding syntax. New developers have to learn how to investigate before they start changing things.
The software development life cycle (SDLC), stage by stage
Software engineering became a structured discipline because early projects kept running over budget, missing deadlines and failing in use. By the late 1960s this was widely called the “software crisis”, a phrase associated with the 1968 NATO Software Engineering Conference in Garmisch, Germany. Brian Randell, one of the editors of the conference report, looks back on it in Fifty Years of Software Engineering. Teams responded with more systematic ways to plan, design, build and maintain software. One of the most widely used is the software development life cycle (SDLC).
Organisations run it differently, but the stages are broadly the same:
- Planning: decide what needs to be built and why.
- Requirements: understand what users and stakeholders need.
- Design: decide how the system should work.
- Development: build the software.
- Testing: check that it works as expected.
- Deployment: make the software available to users.
- Maintenance: fix, improve and adapt the system over time.
AI can help at several of these stages, especially development and testing. It does not remove the need for the process itself.
1. Planning and requirements: understand the problem first
The most valuable lesson for anyone starting a software engineering bootcamp is simple: don’t start coding until you understand the problem.
Requirements can come from a customer, a product manager, a business owner or another internal team. Teams gather them through user interviews, surveys, observation, focus groups, use cases and user stories. That information defines the scope and sets priorities.
Requirements fall into two groups:
| Type | What it describes | Example |
|---|---|---|
| Functional | What the system should do | A user can create an account and log in |
| Non-functional | Qualities or constraints the system must meet | Pages load in under two seconds for 10,000 users at once |
Knowing the difference helps you build software that does more than meet the basic feature request.
2. User stories: connect software to real users
In agile teams, work is often described as user stories rather than detailed technical specifications. For example: As a user, I want to reset my password so that I can get back into my account.
That sentence captures the user’s goal. The team then agrees acceptance criteria that define when the feature is complete. This keeps development tied to user needs instead of treating coding as an isolated exercise. Turning requirements into user stories, acceptance criteria and technical tasks is a core practical skill for beginners.
3. Design: high cohesion, low coupling
Once the requirements are clear, engineers decide how the system should work. They split it into modules, services or components, each with a clear responsibility. Two principles guide good design:
- High cohesion: related functionality belongs together. A user-management component, for example, handles authentication and profile features.
- Low coupling: parts of the system shouldn’t depend on each other more than they need to.
Good design makes software easier to understand, test and change. This is also where AI-generated code can mislead you. A tool may produce code that works but adds unnecessary dependencies or a structure that’s hard to maintain. An engineer needs to spot those consequences.
4. Development: more than making the code work
Development is where design becomes working software, and where programming skills matter most. Good practice means readable code, meaningful names, little duplication and components small enough to manage. Developers also use established design patterns to solve recurring problems.
Modern development relies on tools such as:
- Git, with GitHub or GitLab, for version control
- Pull requests for code review
- Linters and formatters for code quality
- Automated testing frameworks
- CI/CD pipelines for building and deploying software
AI coding assistants can generate boilerplate, suggest implementations, explain unfamiliar libraries and draft tests. But the developer still has to review everything it produces.
5. Testing: part of building, not the final step
Software that seems to work is not the same as software that has been properly tested. Testing catches problems before users do, and each type of test answers a different question:
| Test type | The question it answers |
|---|---|
| Unit test | Does a single function or component behave correctly? |
| Integration test | Do different parts of the system work together? |
| System test | Does the complete application behave correctly? |
| Acceptance test | Does the software meet the user’s requirements? |
| Regression test | Did a new change break something that used to work? |
Automated tests can run in CI/CD pipelines every time the code changes. AI can help write tests and suggest edge cases, but generated tests are only useful if they check the behaviour that matters. The engineer still decides what to test and whether the coverage is meaningful. For a deeper look at balancing these test types, read The Practical Test Pyramid on Martin Fowler’s site.
6. Deployment and observability: surviving outside your laptop
A feature can work perfectly on a developer’s machine and still fail in production. Real users do unexpected things. Traffic spikes. External APIs go down. Databases fill up. Dependencies change.
That’s why engineers think about observability: having enough information about a running system to understand its behaviour and diagnose problems. In practice that means metrics, logs, alerts, traces, performance monitoring and error reporting. The OpenTelemetry concepts guide is a good free introduction. Before deploying a feature, engineers should know what healthy behaviour looks like and what information they’ll need when something goes wrong.
7. Maintenance and the feedback loop
Software development is rarely a straight line. A team builds something, gets feedback, changes it, tests it again and learns from how people use it.
A stakeholder may realise a requirement was misunderstood. Users may struggle with a feature. Production data may reveal a problem nobody saw during development. The team adjusts. That’s why communication matters so much: developers work with product teams, designers, customers and other engineers, asking questions, challenging assumptions and explaining trade-offs. AI can generate code. It can’t replace the conversations that decide whether the team is solving the right problem.
Software engineering career paths
Software engineering is broader than one job title. As you gain experience, you can specialise in the problems you enjoy most:
- Frontend development: building user interfaces and browser-based experiences.
- Backend development: working with servers, databases, APIs and application logic.
- Full-stack development: combining frontend and backend work.
- Mobile development: building apps for Android or iOS.
- DevOps engineering: working with automation, infrastructure and CI/CD.
- Quality assurance engineering: focusing on testing and software quality.
- Data and AI engineering: building data pipelines and the systems behind AI and machine learning.
- Software architecture: designing the structure of larger systems.
- Engineering management: leading engineering teams and technical delivery.
This range is one reason software engineering makes such a flexible career. You can start broad and specialise later.
How to become a software engineer in Kenya
If you want to become a software engineer in Kenya, don’t make learning every new AI tool your priority. Start with the foundations:
- Learn how programming works in one language before adding more.
- Understand data structures and databases.
- Use Git for every project, however small.
- Learn how APIs communicate, then build something that uses one, such as an M-Pesa checkout or a weather app.
- Build complete applications, test them, break them and fix them.
- Put your projects on GitHub so employers can see how you work.
Then bring AI into that workflow. Ask it to explain something you don’t understand. Use it to write a first draft. Ask it to challenge your approach, and compare its solution with your own. Above all, learn to review what it produces. That habit will matter more as AI becomes more capable.
A software engineering bootcamp is one route into this learning, especially one that combines technical foundations with real projects and hands-on development experience.
The engineer still owns the outcome
AI has made producing code easier. That’s a big change, but it doesn’t turn software engineering into a code-generation exercise. Someone still has to understand users’ needs, work within business constraints, design the system, think about security and reliability, test the implementation and monitor what happens after release.
Someone also has to make the uncomfortable calls. Should we ship now or spend another month improving it? Is this technical debt acceptable? Is the risk worth the benefit? Should we redesign the system or make a smaller change? Those decisions are engineering.
For people entering the profession, that’s good news. You don’t need to out-code a machine. You need the skills to understand problems, evaluate solutions and build software responsibly.
AI will keep changing the tools developers use. But software engineering has always been about more than tools. Coding gets software written. Engineering makes sure it’s the right software, built for the right reasons, and able to work in the real world.
Ready to learn how to think and build like a software engineer? Explore Moringa School’s Full Stack Software Engineering Bootcamp and choose the study mode that fits your schedule.
