Back to main page
How Software Development Is Changing, and What It Means for Mooncascade
I spent around 15 years actively involved in Mooncascade’s client projects, working at different times as a hands-on developer, CTO, project manager and analyst. Quite often, these roles overlapped.
During that period, the technology industry changed considerably. Smartphones became the primary computing device for many people, cloud platforms replaced much of the traditional infrastructure, and new areas such as social media, connected devices and IoT created completely new types of products and services. Development tools, programming languages and frameworks also evolved continuously.
Despite all these changes, the basic model of software development remained largely the same. Developers were responsible for translating requirements into code and building software one feature at a time. Better tools made the work more efficient, but people still wrote the code.
Over the past three or four years, that model has started to change in a more fundamental way.
Seeing the change from two perspectives
I am no longer involved in Mooncascade’s daily work. Around two years ago, I started working full-time on my own startup, although I remain an active board member of Mooncascade and stay familiar with what the team is doing, what clients are asking for and what challenges the company is facing.
This gives me a somewhat different perspective from the one I had while working there every day. I can observe the changes taking place in an established software consultancy from a little further away, while my startup has placed me directly back into hands-on product development.
Building a startup with limited resources means trying to move quickly, test ideas early and avoid unnecessary work. It also means using the most effective tools available, which has led me to use AI-assisted development extensively.
Anyone who has been actively using these tools will know how quickly they have developed.
Two years ago, I mainly used AI to generate individual functions, explain unfamiliar code or help solve specific technical problems. The output was useful, but it usually needed adjustment before it could be used.
Today, almost all of the code in my own product is generated by AI, while I focus on defining what should be built, providing context, reviewing the implementation and making sure the result is correct.
AI can inspect an existing codebase, implement features across several components, write tests, run them and fix the problems it finds. It can also improve security and robustness by identifying missing validation, error cases and assumptions that might otherwise be overlooked.
This does not mean that AI builds a complete and reliable product independently. The work has shifted from writing every line of code to directing, reviewing and validating the work produced by coding agents.
Someone still needs to understand the business problem, make architectural decisions, recognise incorrect assumptions and take responsibility for the final result. AI can produce a large amount of good code very quickly, but it can produce a large amount of poor or misleading code just as quickly.
The developer’s role is becoming broader
The largest change is not simply that developers can work faster. The role itself is becoming broader.
Developers increasingly need to organise and direct AI coding agents instead of personally implementing every part of the solution. They need to explain requirements clearly, provide the right technical and business context, divide complex work into manageable tasks and check that the result solves the actual problem.
They also need to recognise when an agent has misunderstood a requirement, selected an unsuitable approach or created a solution that works in the immediate case but will be difficult to maintain.
Understanding code therefore remains essential. In some ways, it becomes even more important when a developer is reviewing a larger volume of code that they did not write personally.
The role is gradually becoming a combination of developer, analyst, architect and project manager. These roles have always overlapped to some extent, especially in smaller teams, but AI is making the overlap much more visible.
Developers are becoming translators between people and AI systems. They turn business needs, which are often incomplete or ambiguous, into instructions that an AI agent can use. They then review the output and ensure that it is safe, maintainable and suitable for the organisation that will depend on it.
Faster coding does not solve every problem
It is easy to assume that if AI makes coding several times faster, software projects should become equally faster and cheaper. In some cases, they do.
A prototype that previously took several weeks may now be created in a few days, and a feature that once required several developers may be delivered by one experienced person working with coding agents.
However, coding has never been the only difficult part of a software project.
Companies still need to decide what they are trying to achieve. Stakeholders still have different expectations, business processes are often poorly documented and existing systems contain dependencies that nobody fully understands. Security, data protection, regulatory requirements and organisational constraints remain important regardless of how quickly the implementation can be generated.
AI performs especially well when the problem is clearly described and the technical environment is reasonably well controlled. It is less reliable when working with a large legacy platform, undocumented business rules or integrations that behave differently from their documentation.
Experience is still important in these situations. AI can help analyse the system and accelerate the work, but it can also accelerate the wrong decision when the person directing it does not understand the wider context.
What this means for software agencies
For software consultancies, this creates both a challenge and an opportunity.
The challenge is that it is becoming harder to treat a development hour as the main unit of value. Some implementation tasks that previously took weeks can now be completed in days, and clients are becoming increasingly aware of this.
A consultancy cannot significantly increase its productivity through AI while continuing to work as though nothing has changed. Clients will expect smaller teams, faster delivery and more flexibility.
At the same time, moving away from hourly billing is not straightforward. Software projects involve uncertainty, changing requirements and technical risks that are not always visible at the beginning. Outcome-based pricing sounds attractive, but agreeing on the value of an outcome and deciding who carries the risk can be difficult.
The industry is still searching for a commercial and operational model that works in an AI-first environment. The difficulty is that the technology changes so quickly that there is currently no stable model to adopt. There may not be one in the near future.
Practices that looked advanced six months ago can already feel outdated today. Pricing changes, tools improve, previously expensive capabilities become common, and workflows that appeared promising can turn out to be too complicated or costly to use in real projects.
This means consultancies need to remain flexible, but not chase every new trend.
Mooncascade has already moved to an AI-first model
Mooncascade has already shifted to an AI-first development model.
AI coding agents are used consistently throughout the company rather than only by a few individual developers experimenting on their own. The company has shared practices for how the tools are used, developers receive training, and teams are expected to stay familiar with the latest capabilities.
The tools are used throughout the development lifecycle, including new product development, testing, refactoring and modernising existing codebases.
Mooncascade is also actively proposing AI-based rapid prototyping for early MVP phases when it is suitable for the project. This makes it possible to turn an idea into something concrete much faster, so that assumptions can be tested before a company commits to a larger and more expensive development programme.
The same tools are useful in legacy projects. Older systems often contain outdated frameworks, accumulated technical debt and sections of code that nobody wants to change because the risks are poorly understood. AI agents can help analyse these codebases, improve test coverage, update dependencies, refactor older components and bring the software closer to current development standards.
This does not make legacy modernisation automatic or risk-free. Someone still needs to understand the system, decide what should be changed and make sure that the changes do not break important business behaviour. AI makes the work faster, but experienced engineers still need to control the process.
For Mooncascade, the question is therefore no longer whether AI should be used in software development. It is already being used. The more difficult question is how to keep improving the way it is used while the tools, costs and recommended practices continue to change.
Not every AI trend makes sense
The speed of change creates pressure to adopt every new idea immediately. In practice, established companies need to be more selective.
Around six months or a year ago, there was a lot of enthusiasm around running large numbers of agents in parallel and building highly autonomous systems where agents would plan, implement and review work with limited human involvement.
Some of those experiments were technically interesting, but I am still not convinced that they made sense for most real software projects.
Running dozens or even hundreds of agents creates its own coordination problems. The agents duplicate work, make conflicting decisions and consume large amounts of computing capacity. Someone still needs to understand what the system is doing and resolve the problems it creates.
The economics are also changing. AI tools were heavily subsidised while providers competed for users and market share. As usage grows and AI companies focus more on sustainable pricing, intensive multi-agent workflows can become expensive very quickly.
An approach that looks impressive in a demonstration may not make sense when it needs to run every day across many client projects.
This is why an established company needs to apply common sense. In Estonian, I would call it talupojamõistus.
The goal is not to use the largest number of agents or the newest tool announced that week. The goal is to find approaches that improve quality, delivery speed or maintainability without creating unnecessary cost and complexity.
Some new developments are worth adopting quickly. Others should be tested, observed and left alone if they do not provide enough practical value.
Being AI-first should not mean being careless.
The wider opportunity around AI
The opportunity for software consultancies is not limited to producing software faster.
Many companies are trying to understand what AI means for their own operations. Some have experimented with public AI tools or added a chatbot to a service, but relatively few have integrated AI deeply into the way they work.
The more useful questions are often related to internal processes. Where are employees still copying information between systems? Which decisions could be supported by better analysis? Which parts of customer service, operations, sales or production involve repetitive knowledge work? Could an AI agent carry out part of a process rather than simply answer questions about it?
Companies also need to understand the risks. They must consider what information can be shared with an AI system, how generated results should be verified, where human approval is still required and how the system can be monitored over time.
Most organisations do not yet have the internal skills to answer these questions confidently.
This is an area where companies such as Mooncascade can be useful. Software consultancies understand systems, integrations, security, data and business processes, and they are also among the earliest serious adopters of AI development tools because the pressure to improve productivity is immediate.
The goal should not be to tell every client that they need more AI. In some cases, a traditional software solution or a simpler process improvement will still be the better answer.
The useful work is identifying where AI can create real value, building it into existing operations in a controlled way and making sure the result remains reliable after the initial demonstration.
The adjustment is also personal
For an experienced developer, moving to an AI-first way of working can be uncomfortable.
Developers have spent years improving their ability to write code. For many, it is also the part of the job they enjoy most. Moving from writing the implementation personally to directing an agent can initially feel as though an important part of the profession is being removed.
In reality, the responsibility remains with the developer. They need to decide what the agent should do, provide enough context, review the output and make sure the result meets the required standard.
This requires learning to trust the tools without trusting them blindly.
It also requires developers to move outside their traditional comfort zone. They need to understand business requirements, ask better questions and take more responsibility for the full result rather than only the technical implementation.
The most useful developer is increasingly someone who can move between the client’s business problem, the technical architecture and the instructions given to AI agents.
The question of junior developers
One of the more difficult questions for the industry is how junior developers will gain experience when AI can perform many of the smaller implementation tasks that were traditionally assigned to them.
Junior developers used to learn by writing relatively simple features, making mistakes and receiving feedback from more experienced colleagues. If those tasks are now generated almost immediately, companies need to find another way to create the same learning opportunities.
Removing junior roles would be a mistake because organisations still need to develop the next generation of experienced engineers. At the same time, asking junior developers to avoid AI and complete everything manually would prepare them for a working environment that is already disappearing.
The learning model will need to combine both approaches.
Junior developers still need to understand programming fundamentals, architecture, testing and security, but they should also learn how to inspect generated code, question design decisions and identify weaknesses in an AI-produced solution.
Being able to explain why a solution works and where it may fail will become more valuable than being able to produce large amounts of routine code manually.
The code was never the whole job
I do not believe that AI will remove the need for software developers or software consultancies, but it will change what clients expect from them.
Companies that mainly sell implementation capacity will find this transition difficult. Companies that understand the client’s business, make good technical decisions and help organisations adopt AI in a controlled and useful way may become more valuable.
The same applies to individual developers. Writing code remains an important skill, but it is becoming only one part of the role. Developers increasingly need to understand the product, the business process, the architecture and the people who will use the result.
The best developers have always worked this way. AI is making these broader skills necessary for almost everyone.
For Mooncascade, the practical approach is to continue using AI throughout the company, follow new developments closely and adopt them when they provide clear value. Since the technology is still moving too quickly for a stable model to emerge, the company also needs to remain willing to change its practices and abandon approaches that no longer make sense.
For most of my career, developers were directly responsible for writing nearly all of the code. AI can now perform much of that work, but people are still responsible for deciding what should be built, whether the proposed solution makes sense and whether the final result can be trusted.
