The premise
Modern software engineering is a discipline that gets harder to talk about every year. The vocabulary has inflated faster than the underlying craft has changed: every framework calls itself a paradigm, every cloud calls itself a platform, every assistant calls itself an agent.
Behind the noise, the work has remained recognisable. A team takes a business need, picks an architecture it can live with, ships a first version that survives contact with users, and then maintains it through three years of change without rewriting it. The teams that do this consistently in 2026 share a small number of habits, and almost none of them are about framework choice.
This piece is about what modern software engineering actually delivers, and where AI has and has not changed the engineering itself.
The cost of getting the architecture wrong has not gone down
Frameworks evolved. The cost of a wrong foundational choice did not.
A common claim in 2026 is that AI-assisted development has made software cheap. It has made some software faster. Faster is not the same as cheaper, because the work that gets compressed by AI assistance (the typing) was rarely the expensive part. The expensive parts are still the same: choosing the right architecture, modelling the domain correctly, deciding what to ship and what to refuse, and maintaining the result for years.
A misjudged data model is still a multi-quarter problem. A misjudged authentication boundary still leaks customers' data. A misjudged deployment story still wakes the on-call engineer at 03:14. None of these classes of mistake are solved by faster typing. They are solved by senior judgment at the design stage, the part of the work that AI assists with, but does not replace.
The teams that ship software in 2026 spend more time on the early architectural decisions than they did five years ago, because the cost of getting them wrong compounds faster across an AI-augmented codebase.
Boring defaults, opinionated where it matters
The SDEN default stack for web and mobile is deliberately conservative: Next.js with TypeScript on the front, PostgreSQL with Prisma or Drizzle on the data layer, Node.js or a framework like NestJS on the API surface. Mobile defaults to Flutter or React Native unless the product needs deep platform integration. The point is not that these are the trendiest choices. It is that they are the choices a small senior team can still maintain three years from now.
Where we are opinionated is the boundaries: typed APIs end-to-end, server-rendered by default, no untyped data crossing between server and client, a CI pipeline that builds and deploys every commit on the main branch, and a release process automated enough that the engineer who shipped the change is not the engineer who watches the deploy.
These are not exciting choices. They are the choices that make exciting work possible later, because the team is not spending its energy on the fundamentals.
The patterns that survive the second year
Most software projects feel fine in the first six months. The interesting tests come in the second year, when the original engineers have rotated off, the product has accumulated edge cases, and the customer base has expanded beyond the design assumptions. The patterns that survive that test are the boring ones: explicit module boundaries, a domain model documented in the code rather than in a wiki, an architecture decision record for every non-obvious choice, and a test suite that someone can still run.
The patterns that do not survive are the ones that depended on a single engineer's memory, a framework's defaults staying constant, or the assumption that nobody would ever want to look at this code again. They always do.
SDEN's bias on every engagement is toward the boring pattern, accepted explicitly and documented. We will trade away cleverness for legibility on the second year of every project.
Three habits behind every codebase we hand over
These are not aspirational. They are the operating defaults on every engagement, written into the engagement contract.
Typed end-to-end
TypeScript across the full stack, with no untyped boundary between server and client. If a field changes in the database, the front-end refuses to compile until the change is acknowledged. This is the cheapest large-team safety net we know.
Architecture decision records
Every non-obvious choice gets a one-page ADR in the repository: what we decided, what we considered, why we picked one over the other. Future engineers, including ours, read these on day one.
Boring deployment
The deploy is automated, observable, and reversible. Any engineer on the team can ship to production; any engineer on the team can roll back. The release process is not a ritual.
The codebase you can still read in three years
The honest measure of an engagement is what the next team thinks of the code.
A codebase that ages well does not have a single trick to it. It has a hundred small mercies: meaningful names, modules sized for one person to hold in their head, tests that explain the intent behind the code, no dead code lying around to confuse the next reader, and an architecture decision record at every junction where a future engineer would otherwise have to guess.
When SDEN hands a codebase over, the test is concrete: a senior engineer joining the project should be productive in under a week, without a hand-holding tour. If they cannot, we have not finished.
This is the boring half of the work. It is also the half that determines whether the product survives the next change in the team.
Software & Mobile
questions we get asked.
Direct answers to the questions we get asked the most. If yours isn't covered, write to the team.