The definition of an artisan in Wikipedia:

An artisan (from French: artisan, Italian: artigiano) is a skilled craft worker who makes or creates material objects partly or entirely by hand.

Apart from “material objects”, the definition sounds exactly like the definition of a Software Engineer before ca 2024. Especially when you consider that each item was effectively a unique creation, and historically, the tolerances (defects, reliability, proximity of functionality to desired outcome) had an extremely high variability.

AI changes this. We are no longer hand-crafting every line of code. Writing code was never the only skill required of a good Software Engineer, but it was a central one. We are now moving towards one where the emphasis is wholly moving towards figuring out the why and what to build, defining inputs (specification), and verifying this against output within some tolerance. We are also dealing with a much higher volume of output than before.

This move from artisanally hand-crafted code being informally verified (hopefully with some unit-, integration- and acceptance tests + some manual testing, usually varying from team to team), to verifying high volume AI manufactured code is shifting the demands of the profession fundamentally. Writing a few tests, and clicking around a bit isn’t going to cut it anymore, when we are looking at a veritable fire hose of code.

The death of the Software Engineer is greatly exaggerated

Why do we even need Software Engineers if AI is writing all the code? All we have to do is tell the AI what sort of thing we want to build, right?

Right. This works fine for vibe-coding a small app or website. It is true that AI is democratizing software creation. Except..

For anything of non-trivial size and/or complexity, you need to make sure you specify precisely and unambiguously, in such a way that there is no room for the AI to confidently fill the gaps with bad assumptions. You must be explicit about:

• Edge cases and failure scenarios.

• Scalability constraints.

• Interactions between the new spec and prior specifications.

Sounds a lot like engineering, huh? Add to that the fact that English, and every other language spoken by humans, are inherently lossy and ambiguous. The shift from artisanally hand-crafted code, to a fire hose of specification generated code will actually require more discipline, more structure than we have ever applied in our field before. The scale of what we now can do demands it.

Drinking from the fire hose: the verification crisis

The burden of verification is growing exponentially. Line-by-line code review will wither and die in all but the most sensitive fields (and perhaps even there). Hand-crafted test-code will go the way of hand-crafted production code, we simply won’t be able to keep it up. We can try to instruct AI to do TDD, to write tests as it goes along, but even here the AI will be incentivized to write tests that pass, rather than rigorously test its own output.

The consequence of this is, that we will be forced to come up with new, novel approaches to automating our verification, how close to our intent our output is.

What these approaches are, I can only speculate on, and we’ll likely discover things along the way as things evolve, just as we have these past few years. But I would make an early guess that some of the approaches will be a combination of:

1. AI-on-AI auditing: Using “Critic” models to find hallucinations in “Generator” outputs.

2. Property-based testing: Moving from testing specific examples (e.g., 2+2=4) to testing invariants (e.g., A+B must always equal B+A across all possible inputs).

3. Formal & Probability-based verification: Mathematical proofs of correctness to ensure systems stay within non-functional requirement tolerances.

Conclusion: the Expertise paradox

The great irony of Software Engineering in the age of AI, is that we will need to become even more of an expert than before. Relying on vibe-coding, or doing things “the way we used to” will only result in drowning in a mountain of garbage and technical debt. A new level of discipline, skill, and ability to create reliable feedback- and verification loops will be required.

This shift has an interesting characteristic: it will increase demand for these skills (expect more demand for software engineers), while at the same time creating a brutal shake-out of those in the industry incapable of adapting. Increased demand for higher level of skills, but reduced supply likely means those who can make the jump will be paid a handsome premium compared to today’s software engineers.

The age of the Software Artisan is coming to an end. Industrial scale production of software means we are finally crossing over into a proper rigorous discipline called Software Engineering.

For thirty years, the standard playbook of lowering cost of software production was to move high cost software development from places like San Francisco, New York, London or Zurich, to low-cost locations like Pune, Bangalore or Manila.

We are now moving to a world where this will be akin to a corporate suicide note. The arithmetic is simple: the cost of producing software is falling close to zero.

In a world where the actual effort to write code is 10% of what it was a few years ago, how much are you really saving by having an engineer at half the salary on the other side of the planet, compared to how much you are losing in cycle-time due to timezones, and context by using a less skilled worker who doesn’t know your business?

The latency tax: the killer of time-to-market

AI allows us to build and move faster than ever before. This means we can reduce our cycle time for change and new features from days and weeks, to mere hours. An idea can be built, refined and demoed, multiple times in a single day.

In a vicious competitive landscape, who wins, the actor who can iterate and refine a value proposition 5-8x in a single day, or the actor who can do exactly one cycle every 24 hours, because timezone incompatibilities means they have a brief window of overlap once a day?

That cost-per-seat with your offshore provider will seem costlier than ever, when the competition is moving 5x faster. Even at half the salary, you are effectively paying 5x more for the same result per unit of time, all things being equal.

And all things are rarely equal, as we’ll soon discuss.

The context tax: the killer of quality

The second thing is, people working closely together, iterating on a problem, will always outperform disengaged people turning JIRA tickets they fully do not grasp the purpose of.

With increased speed of iteration, clarity of purpose becomes more important than ever - having a shared understanding of what you are trying to achieve, and more importantly why, will be competitive advantages.

Feeding people with ill-defined JIRA tickets, who then feed them onwards to AI assistants are going to combine the absolute worst aspects of offshore development with the worst aspects of generative AI: a drift between desired- and actual outcomes, and plenty of inferred bad assumptions and AI hallucinations to fill the gap.

Context + purpose eats cost savings and Taylorism for breakfast in the old world. AI grows it from a gap, to an ocean.

The Token Arbitrage

Historically, the unit of cost in software was the hour of human work. In the future, the unit of cost is the cost of tokens.

When a local/onshore engineer who truly understands the business they are working in, and the problem they are working on, is given a high token budget to use leading edge AI Assistants (such as Claude Code currently), combined with frontier models, working at a Level 7 of AI Assisted Software Engineering, they effectively become an industrial factory of automation and software creation.

The typical offshore firm’s model built on billable hours: they are incentivized to keep headcount high and processes manual. Conversely, a high-skill onshore lead aligned with the organization they are working in is incentivized to automate themselves out of everything mundane and repetitive.

The outcome is a $200,000/year engineer with a monthly $5,000 compute- and token budget can now outperform and run rings around a $1000,000/year managed offshore team. The premium paid for an “Architect-Orchestrator” isn’t an expense, it’s the most efficient CAPEX investment you can make.

Conclusion

The era of geographic labor arbitrage was built on a simple assumption: human labor was the scarcest resource in software. AI has completely up-ended this assumption - human labor is no longer the key input for ROI per unit of time.

The new math of software production looks like this:

Velocity + Context + Compute > Cheap Labor

If you continue to optimize for the lowest hourly rate, you are effectively choosing to pay a 400-500% tax, while reducing your chances of survival. You are choosing to be slower in a world that is moving faster. You are choosing to be “lost in translation” in a world where context is the only moat left.

The winners of the next decade won’t be companies that best optimize their blended cost of labor. The winners will be lean, high-context teams located in the same timezone, fueled by sufficient token budgets, turning ideas into reality and testing them on real customers before their offshore-reliant competitors have even finished their morning stand-up.

The map of the software world is being redrawn. The future belongs to the Product Engineer.

Software engineering isn’t being replaced, it is both becoming a purer form of what it always was, and something entirely different to what it has been.

As of early 2026, I have observed a natural progression in how we work with AI. It is an evolution of maturity: moving from AI as a better “search engine” to AI as a self-correcting industrial system. But there is a cliff edge ahead. If you are clinging to Level 0-2 by 2028, you will be professionally irrelevant. Stubbornly clinging to hand-crafted syntax today is as futile as the Luddites destroying knitting frames in 1811. You may be a skilled artisan, but your hobby has no place in a professional production line that requires a scale, speed, and quality you simply cannot match manually.

Why? Because the technical friction and cost of construction, bringing an idea to code, has evaporated and is fast approaching zero.

Level 0: Classic software engineering

Self-explanatory: you are not using AI. You are using your IDE like it’s January 2021, relying on dumb-autocompletion, refactoring tools and symbol navigation.

In 2026, this is the equivalent of trying to solve the western housing crisis by building log cabins equipped with only a saw and the power of your muscles: you’ll probably produce something small and beautiful, but by comparison, you’re not making a dent into the underlying problem.

Doing this is fine, if you enjoy the tactile experience of typing out code as a hobby, but it’s best to acknowledge what it is.

Level 1: Assisted software engineering

This is where we all started sometime in the second half of 2021 or early 2022: when Github Copilot first came out, it was an auto-complete on steroids. Copy-pasting from asking ChatGPT questions was also a revelation in terms of having a better, compressed, but sometimes hallucinating search over StackOverflow. Where you could get blocked for days working a problem before 2021, all of a sudden, you had the power at your disposal to, mostly, get unstuck after a few rounds of asking.

Level 2: Integrated assisted software engineering

Eventually, Copilot and other tools evolved to the point where you got a chat-bar in your IDE. You could give the chat a set of files as context, ask questions or request solutions, that you had the option of merging into your selected files.

It seems a long time ago when this was the state-of-the-art, if you think second half of 2024 was a long time ago! It just goes to show how quickly things evolve, when the approaches we used 18 months ago already feel ancient.

Level 3: Agentic vibe coding

Vibe coding in agent-mode is probably where most of the industry sits today in terms of Software Engineering AI maturity: you have either “agent-mode” turned on in Github Copilot in your IDE, or you’ve started using Claude Code, or some other CLI based tool.

At this level, it’s possible to ask your tool harder questions, or complete harder problems, often with context, but even with incomplete context (in terms of files), the agent will find a way to make at least a competent attempt at solving the problem you have asked it to solve.

The issue at level 3 is, that quite often the guardrails and specifications for what you want to achieve are insufficient for your AI assistant to fully complete, or complete without issues. Another problem is that you often have to re-explain yourself to your assistant when you start a new session, causing unnecessary waste of time in repeating yourself.

This often leads to the realization that we need level 4…

Level 4: Structured vibe coding

The first step to moving beyond vibe coding is the realization you need a bit more structure to the process than simply “talking” to the agent and incrementally correct it, reduce ambiguity.

This is usually when you:

• Start writing instructions to your agent in things like the CLAUDE.md file.

• Start writing down tasks and requirements for your assistant, perhaps even using the agent as an assistant to drive out ambiguity and refine the requirements.

• Ask the assistant to write a markdown file keeping track of learnings, what we want to do, what we have done etc. A “Save game” of sorts, to borrow video game terminology.

• Perhaps have the assistant generate some architectural documentation as well, speeding up “relearning” between sessions.

Somewhere at level 3 or 4, you might also find yourself, depending on the task at hand, reviewing code more than actively participating in writing.

Level 5: The Manager of Agents

Some of the structure we are starting to adopt at level 4 quickly leads to the realization that many of the tasks are predictable- and/or repetitive.

This naturally leads into starting to define tasks and agents for the work that you can foresee.

All that documentation needs to be kept up-to-date. It makes sense to have a documentation expert agent, and perhaps a skill to invoke with a default template.

Requirements refinement? A domain expert BA sub-agent persona, who thoroughly analyzes and audits requirements, as well as their consistency with prior requirements, calling out any conflicts.

Security experts, DevOps engineer, depending on the project, use your imagination. Just a word of caution: perhaps don’t replicate full Taylorism, have agents and skills that make sense. But if you valued TDD prior to 2025, probably having a “Test agent” doesn’t make sense, make your agent write its own unit tests.

Level 6: Cognitive Engineering

The increased structure of starting to define tasks and agent roles often leads to the next “aha”-moment:

Our job as software engineers, as far as producing the actual software, has evolved from writing code and tests, to defining a harness for our agents, consisting of:

• The big picture “North Star” problem and domain we are solving for.

• The architectural vision and how it links to the North Star.

• Principles of engineering, patterns and architecture we want to follow.

• Constraints, non-functional requirements and “Do not”-rules.

• Unambiguous, internally consistent requirements, which can be directly translated to code.

However, the big structural challenge when reaching this level is, how do we organize this harness of constraints and knowledge in such a way, that loss of context between sessions and context-compactions is minimal, even when working on large tasks?

Answering this question requires us to become structured, such that we can store all this information in-repository in a way that makes it amenable for recall. The best analogy I currently use for this is mimicking human long-term memory, which is divided into three key parts:

• Episodic memory: how we remember what happened, when, and in which order things happened.

• Semantic memory: General knowledge, concepts and facts we’ve learned through the work.

• Procedural memory: how we know how to perform tasks and processes almost unconsciously.

Thinking of the problem in this way, means we have to get structured about how we store, interlink and shape all the different types of documents in our repository. We are no longer writing code or even directly working on the software we are producing, we are meta-engineering the long-term memory and brain of a team of agents.

As your confidence grows at this level, and you have found a system that works for the domain, you might find yourself spending less and less time reviewing the code that is being produced, because you trust it.

Level 7: Blackbox Intent Engineering

At this point, we have built skills, teams of sub-agents, we have engineered long-term memory and context for our agents, and if we’ve done it well, we are starting to note that the code mostly “just works”, even for large sets of features.

We have firmly shifted the bottleneck of software production from creation to review & verification. We might have some level of trust in the code, as well as the unit- and integration-tests that our agents are producing, but how can we be absolutely sure it works as intended under all circumstances without human inspection and testing?

Turns out we can borrow inspiration from existing disciplines, on how ML- and AI systems are traditionally trained, and formal verification:

We split the agentic system, into two parts: The Producer and The Verifier. The Verifier is intentionally “blind” to the source code. It only sees your high-level intent. Your job as the engineer is to define the Formal Specification that the Verifier uses to hunt for failures:

• Scenarios: The “Happy Path” and edge-case journeys the system must survive.

• Properties: Behavioural contracts, which should hold under all circumstances, for instance “each processed payment should produce an ‘Invoice Generated’ event”.

• Invariants: Systemic truths that can never be violated, for instance ”The sum of all allocated stock must never exceed the physical warehouse capacity”.

Equipped with these, you can then setup your second agentic system (without access to code, but access to system and tools to exercise the system), to create agentic loops which obviously verify that the happy path system works, but also create “Red Team” adversarial loops which try to break the system, both from a specification, as well as performance and security perspective.

By splitting the production from verification, you have also done away with one of the biggest weaknesses of AI aided development over recent years: the propensity of coding agents to write tests that pass, either by undermining functionality or testing.

When the Producer writes code that passes the Verifier swarms adversarial stress tests, you no longer need to read the code. You have empirical proof of correctness.

The New reality of Software Engineering

Many teams have hit a ceiling at Level 3, this is the current mainstream “state-of-the-art” of the industry. But it is far below what is practically possible, as of now.

Software production has been democratized, made possible, much like photography was democratized by digital cameras. This didn’t mean that photographers went extinct though. The same is true of Software Engineering, we are evolving from multi-functional artisans of code, to meta-enginers of systems of agents, memory and intent. The work we used to do at Level 0, will now shift to being done mostly at mutually inclusive and complementary Levels 5 to 7.

In a sense, our job has now finally become what we were always meant to do: Solve problems at the intersection of business, humans, and technology, not just writing syntax.

I will come back later with posts and guides specifically on Levels 6 and 7, if you want to read these, please subscribe!

I wrote in late 2024 about how I use AI for Software Engineering. 12-14 months is a lifetime in this tech cycle, and as a consequence, my entire workflow has completely changed. I expect it to change as much in the next 12 months, so this is an ever evolving topic.

If you read this after July 2026 and think “this is stupid!”, it’s quite likely you are right, because things might have changed again. What is clear, is we have come a long way from vibe-coding and autocomplete on steroids.

The Seven Pillars

There are seven pillars to my current workflow. We will go into the detail of each below, and I will start from what is likely familiar to people, and move our way towards perhaps less mainstream, but hyper-effective approaches.

The Tooling: Claude Code

My weapon of Choice since spring of 2025 is Claude Code. At first, I was skeptical of the CLI based approach over the IDE-integrated approach, but as I got used to it, I quickly realized it is superior to the alternatives:

• We can use whatever editor we want to view code.

• The CLI can go off and use whatever tools it needs to do its work.

• We can integrate the CLI tool into CI pipelines and other automated workflows.

Freeing our AI assistant from the confines of a desktop application really opens up possibilities.

What is my take on other tools? Github Copilot has come a long way. It’s probably 3-6 months behind Claude, and if your organization is on Copilot, there is no pressing need to switch, but do know you are somewhat behind of being able to do the most powerful use-cases.

Agents & Skills

Let’s first set the scene, with what each means in layman terms: an agent can be seen as an independent process, with its own context (thus not using the size of the main context), that communicates with the main context, but executes tasks and responsibilities that it is assigned as appropriate.

“Skills” I view effectively as reusable prompts for repetitive and/or frequently used tasks. If you view skills in this light, you’ll quickly figure out exactly what skills you need for your specific project: things you need to do frequently and consistently.

What Agents should I have?

Some people go nuts with agents: they’ll have a frontend agent, backend agent, architect agent, unit-test agent and so on. I actually do not buy into this approach: if you consider how humans build cohesive systems, it is not by splitting responsibility across every technical silo possible - this is in fact a means of creating disjointed, poorly architected systems. I find it better to put these responsibilities into the overall Claude instructions: such as “all code should have adequate unit-test coverage, covering both happy- and negative path cases”.

Where I do find agents come in handy, is as domain-experts and executors of ancillary tasks. Some examples:

• Documentation Agent: responsible for continuously updating documentation, if relevant, as code changes.

• Business Domain Expert Agent: reviews requirements and code, such that they actually make sense in the context of the system and domain you are building.

• Code Review & Rule Expert Agent: Solely passive agent that calls out when we duplicate code, write tests that are written to pass, rather than test functionality, violate architectural rules etc.

• Requirements Reconciliation Agent: An agent that keeps track of your new work and compares it to past requirements, such that any logical conflicts between new and old requirements can be called out and reconciled.

• Security Agent: reviews code for security vulnerabilities.

Requirements Engineering

One fallacy of the AI era is that software engineering is going away. It is not. The level of abstraction is just being raised, same as when we went from punch cards to in-computer code, from manual memory management to garbage collection, and from procedural code to object-oriented and/or functional programming.

In the age of AI, the bulk of engineering will happen at the level of refining requirements to a size and specificity that is appropriate for AI. AI works exceedingly well for solving well-defined, unambiguous problems. It still falls apart if a problem is ambiguous, or there are edges which are ambiguous. If you look at most of what is put into JIRA and similar tools, or into product description documents by non-technical product managers, business analysts and users, you’ll find that the level of ambiguity and lack of specificity will make AI generated solutions mostly fall apart at any scale beyond a single requirement.

So in early 2026, what is the ideal loop for requirements?

This is how I go about it:

1. Write out a requirement in Markdown, as specific as possible.

2. Ask Claude to call out ambiguity in the requirement and ask any questions required to make it unambiguous.

3. Refine collaboratively until Claude is happy.

4. Reset the context window, go back to 2). Repeat until such time Claude, with a clean context, considers the requirement entirely unambiguous and clear to implement.

5. If the requirement is larger than what would be a simple task for a human, ask Claude to break it down into sub-tasks.

6. Again, repeat until you are confident of the specificity and clarity of each step.

7. Start implementation.

The intent of this loop is to effectively have a plain-language, unambiguous and very clear idea of what is being built, what the edge-cases are and how they will be dealt with, how it fits into the greater context of the system, and how it can be broken down into smaller tasks, if necessary.

It is also useful to keep requirements and tasks broken down, in a structured folder and Markdown format, such that a historical record of requirements and decisions can be accessible both for you as the engineer, and for the AI, to later find and explain why certain things work the way they do, and call out potential conflicting requirements, and how to resolve them, in the future.

But this alone is not enough, this is why we must continuously do the following steps as well:

Non-functional Requirements & Rules

We should create unambiguous documentation for our AI assistant of all non-functional rules and requirements that we should adhere to. This should include things such as:

• Our tech-stack.

• Rules around testing.

• Preferred patterns and code style: do’s and don’t’s.

• Levels of linting.

• Verification steps before considering a task done (run tests, lints etc).

• ..anything else that is not technically a requirement, but considered a non-negotiable rule.

If you are only setting up a new project, I’d suggest you again, use your AI assistant to collaboratively build out this requirements- and rule-set, as you discuss potential architectural choices and tech stacks.

Automated Documentation

For your AI assistant to easily understand the system that is built when starting a new session, and also for humans who come onboard, automated documentation is essential.

In the old world, documentation was frequently stale as soon as you’d done the first commit of a README.md, however, as I mentioned in the Agents & Skills-section, with a dedicated documentation agent, documentation does never need to be outdated.

If you start automating documentation from the start, this would be the ideal case, but you can also bootstrap documentation after the fact on existing systems through a process of Socratic questioning, and focusing on infrastructural files as entry points for your AI to start exploring (think Dockerfiles, K8S manifests, build files etc).

What you would hope to produce is:

• An entry point README.md for your documentation.

• Comprehensive documentation, both in the form of Markdown, and Mermaid diagrams embedded in the markdown, this should contain:

  • Architectural documentation.

  • Overall purpose of the system.

  • Technical principles and rules (your non-functional requirements and rules from before).

  • Architectural Design Records that explain technical decisions that have been made thus far, when they are of architectural significance.

  • Your requirements log.

Doing this, and automating it has several key benefits:

• Your AI will never get lost in what the system is about, and neither will you.

• You will have a comprehensive audit-trail of how the system has evolved, and why.

• New conflicting requirements can be reconciled against old requirements, to find a way forward, without breaking the intent of old requirements.

One point of note though, to not drown in documentation, it is worth also instructing the documentation agent in its definition, to not be shy about removing documentation that is out of date.

“Save Game files”: the Secret for Continuity

One pattern I frequently follow when doing larger changes that may span several days (yes, this still happens even in the age of AI), is that I request my assistant to keep a running log of what it has done so far, what is left to do, and what it has learned around solving non-trivial problems in the process. This is so that when I continue in a new session the next day, I won’t have to remember the details myself, nor reteach or retrace past steps with my assistant.

If you’re just vibe-coding a simple webapp with two features, this may seem superfluous, but on any system of sufficient size and complexity, eventually you will come in contact with changes that are non-trivial to complete in a single day.

AI in CI

Reading everything we’ve gone through so far might leave you thinking “couldn’t we further automate some of these steps?”.

And you’d be absolutely right! When it comes to how far we can go in embedding AI in our CI pipelines, only our imagination is the limit, if we use CLI-based tooling.

The obvious steps are:

• PR reviews, based on our rules and documentation.

• Automated documentation updates.

• Security reviews.

• ..and much, much more.

Key Takeaways for the 2026 Software Engineer

• Precision is the new Syntax: Your ability to eliminate ambiguity in requirements is now more important than your ability to remember library APIs.

• Context is King: The difference between a “vibe-coded” mess and a production-grade system is the quality of the non-functional rules and documentation you provide your agents.

• The CLI is the Workflow Engine: Moving away from the IDE-integrated “chat box” toward CLI-based tools like Claude Code allows for the automation and pipeline integration that professional systems require.

• Continuity over Speed: Using “Save Game” files and automated ADRs (Architectural Design Records) ensures that the speed of AI doesn’t lead to a technical debt trap.

Conclusion: The Rise of the Logic Architect

We are witnessing a fundamental shift in the “unit of work” for a software engineer. We used to measure ourselves by the code we wrote - today, we measure it in the clarity of our mental models and the robustness of our agentic workflows.

If you feel like you’re spending more time writing Markdown than JavaScript, don’t worry, you’re doing it right. You are no longer just a coder; you are a Logic Architect. Your job is to build the constraints, the rules, and the context that allow AI to execute with 100% precision.

The “seven pillars” I’ve outlined here aren’t just about being faster - they are about being more intentional. In a world where AI can generate a thousand lines of code in seconds, the human engineer’s most valuable contribution is ensuring that every single one of those lines actually belong there.

See you in 12 months for the next update, unless the agents haven’t rewritten this blog for me by then.

The discussion about AI-generated code, whether coming from hype-merchants, or skeptics, frequently makes it sound as if you should stop thinking about the code and architecture and just accept it as is, once it compiles and seemingly works.

Nothing could be further from the truth: AI-generated code does not absolve the developer from thinking about code, architecture, tests, refactoring, edge-cases etc. All it absolves us from doing is some of the typing!

I generate a lot of my code these days. I rarely accept it at face value. I almost always spend significant time refactoring what I’ve received, thinking about edge-cases and tests I’ll need. And I have an active discussion with my AI assistant about these things. What generated code has allowed me to do is focus my on what matters, and save energy on typing out boilerplate.

What is an LLM capable of, really?

LLM’s, somewhat simplified, are not real intelligence, but a combination of three things:

• Autocomplete on steroids.

• A compressed, lossy search across the LLM’s training corpus (compressed, lossy = hallucinations).

• Conversational search across the above, predicting the most likely/wanted response to a query.

The last point is key. We should not anthropomorphize AI, but if we are to do it, I think we can translate the “most likely/wanted response”, into thinking about an LLM as a sycophant - it will tell you what you want to hear.

The second order consequence of an LLM as a sycophant, is that if you ask it to write your unit-tests, there is a high risk/chance it will generate tests that pass if possible, even if the code tested contains obvious bugs. This means a few things:

• You can never fully trust tests written by an LLM without thorough human inspection.

• You can increase trust by prompting with a high degree of specificity of the criteria to pass.

• You need to question edge-cases that are likely not covered.

Now, if you do the last two things, the lines are blurring between code and natural language, don’t you think? This doesn’t mean we can’t work this way, or that it isn’t useful. However, it does mean that we still need to have in-depth awareness of the problem we are solving, and how it interacts with the code we are using, writing and generating.

I discussed tests here, but obviously all of the above here also applies to implementation code! Just because you didn’t test it, or see a failing test, doesn’t mean there aren’t bugs lurking.

AI only helps with autocomplete?

In a word: No.

As I previously wrote, I think we are only starting to scratch the surface of what AI assistants are capable of, but we also need to learn to work with them, and understand their limitations.

Some ways I have found AI Assistants to help:

• Code generation

• Inspection/review: did we catch all edge-cases? Are there any issues?

• Interactive documentation: How does this code or API work? If I do A, are my assumptions correct?

• Getting unstuck: “better, contextual StackOverflow”

• Architecture feedback: describe my architectural ideas, get feedback on trade-offs.

But, remember what I said earlier: your Assistant is a sycophant! You need to take all feedback and code generated in consideration with a critical mind. The model might just be telling you what it thinks you want to hear, not what is most useful.

So how much time and cognitive load do I save?

This is the billion-dollar question.

My feeling is that, like many other technological improvements over the last 50 years, we yet again reduce time used, and cognitive load of low-value work.

Calculators did not replace mathematicians or undermine the value of mathematical knowledge.

What AI Assistants save software engineers is in typing, remembering API’s & documentation, and having interactive feedback on work, without always requiring a physical human as your pair programming partner.

The result is, we will spend less time typing out code, and more time thinking about the problem to be solved. This will certainly reduce the time and cost of producing software. But as any seasoned professional will know, conceptualizing a solution, and in particular, writing the code, is only a small portion of the problem software engineers solve.

Conclusion

If AI Assistants only touch a small surface area of what software engineers do, are they useful?

The answer to that is a resounding “Yes!”. They are useful in the same way calculators and spreadsheets are useful to mathematicians and statisticians.

They won’t do the high-level thinking and problem-solving for us, but they will certainly aid us in doing it, by providing feedback and reducing the cognitive load of low-level details.

Personally, more often than not, I have an idea of the direction I want to go in to solve a problem, but in the past, going from idea to solution was broken up by a LOT of typing code, looking at documentation, getting stuck on small, but non-obvious bugs.

If I can do less of that grunt work, and more of the more fulfilling thinking, I will not only be more productive, but also a lot happier in what I do. I think this goes for almost anyone.

We should embrace our brave new world, but keep our expectations grounded in what the tools can- and cannot do at any point of progress. This is how we ensure we stay at the leading edge of progress, without wasting time going down blind alleys of false promise.

I have been on the Generative AI train since before day one. My first brushes with Natural Language Processing (NLP) go as far back as 2008. I founded a startup that focused on NLP applications for financial markets trading systems in 2011.

Even with a deep background, I was blown away when first GPT 3 and later GPT 4 came out, and I started integrating them into my workflows immediately, to the point where today, Generative AI are an integral part of my daily workflows.

They are immensely useful, productivity boosting. I’ve previously written at length about how I use them for some of my work.

But with deep familiarity also comes awareness of the limits and shortcomings of current, and likely immediately coming generations of software: hallucinations are not getting better. Reasoning is lacking. They get stuck in local maxima and loops, and much more. These issues don’t look to go away, as we have practically exhausted all sources of training data, and improvements are now primarily focused on the inference side.

To make a long story short: to make significant progress from where we are today, we will need to make several, as of now, unknown scientific discoveries. Sure, we can polish what we have and make it smoother, less error-prone, but it ain’t AGI.

Unreasonable business risks of replacement

So we have an AI that hallucinates, gets things wrong 10-20% of the time (conservatively estimated), and lacks reasoning.

Where does that leave us in terms of unsupervised operation? What human tasks in business are acceptable with these sorts of problems?

Call-centers and customer support have been mooted as one area, and Klarna claims to have made massive inroads here (nothing to do with an overfunded company struggling to live up to past funding rounds valuations, wanting to boost it by being an “AI company”, but I digress).

I’m not sure if I buy it: sure, call-centers and customer support may be candidates, IF you are happy with basically an interactive FAQ style level of customer support. But for how many businesses will this be acceptable? Also, if the LLM Agent hallucinates discounts, rewards or refund policies, businesses have to fulfill them, is this going to be ok?

Let’s move up the stack to more intellectually demanding jobs: programmers seem to be on the shopping block quite a lot. But if LLM produced code is wrong 10-20% of the time, and it is uncritically deployed to production, it is probably going to be a business ending issue a relatively high percentage of the time.

Fire all the programmers, who are equipped to evaluate the output, while letting managers and business analysts dictate to an LLM? Good luck.

Who is getting replaced anyway?

It’s undeniable that AI will allow us to do more with less, I already wrote about the paradoxical increase in demand for human intelligence that will result from this.

But let’s assume for a second we simply keep doing the same things as today, with fewer resources, and let’s focus on technology.

Who is best equipped to “manage” AI, evaluate and correct its output? Undeniably, it will be software engineers. So in practice, it is simply an evolution of the profession: writing even less code (coding is only a fraction of what software engineers do), spending more time reading code.

In practice, we’ll see increased demand for software engineers with a flair for product management, prioritization and evaluating trade-offs. The profession will become more demanding, and the bottom 10-20% of “code monkeys” will be cut loose, as their value add in this new reality is negligible.

What are the secondary effects of engineers taking on more responsibilities? We’ll see reduced demand for the ancillary skill sets and roles. Non-technical Business Analysts are on thin ice. Product Managers will continue to exist, but there will be fewer of them. Manual testers have long been disappearing and will continue to do so.

So if the above comes to pass, there will be significantly fewer people to manage. What, then, happens to the managerial classes, when there are fewer, more self-organizing people to manage? I’ll let you finish my next sentence on your own.

The fallacy of replacing “the doing”

The fundamental fallacy of theories of job displacement through technology is that those with the expertise in doing the work will get replaced, while those without it (managers, analysts) will assume their responsibilities.

This is an assumption based on hierarchy, not fact. Feeding the foot soldiers to the grinder, while those “above” are safe.

If you instead turn to assumptions and questions based on unit-economics, the outcomes become quite different. Whose economic output is likely to be increased the most by new technology? Whose skill set is likely to be increased the least? If fewer people will indeed be required, what roles and overheads will disappear?

Conclusion

My thesis is, given the error rates of Generative AI, fewer jobs than we think will be entirely displaced, even low-end ones.

The current zeitgeist around displacement is also wrong: applying a lens of whose output is most likely to benefit from new technology, and who is most adept at managing it, means these assumptions will be turned on their heads.

Finally, being able to do more with less, is primarily detrimental to roles that are overheads in relation to the doing: the roles that are necessary evils when managing at scale, but which may be surplus to requirements as team-sizes to achieve the same thing shrinks.

When intelligence becomes abundant, demand for it will explode. This is something we can easily see from history, and what is called Jevons Paradox: When a resource becomes more effective to use, and radically cheaper, demand paradoxically increases.

When electricity became cheap, we didn’t stick with replacing our means of lighting. We replaced heating, eventually food preparation. We invented radio, refrigeration and more new technologies than earlier thought possible, because we got abundant, cheap energy. When calculators became mainstream, mathematical knowledge didn’t lose its value, the value of it rose through its leveraged application.

The same thing will happen as intelligence becomes abundant with the entry of generative AI.

Doing things that were too small & costly before

The obvious case of what will happen: We’ll do the same things with fewer people and less resources. This is the focus of the current Zeitgeist, and what people with a static, unimaginative mindset believe will lead to mass unemployment by people displaced by AI.

Some displacement will inevitably happen, but the opportunities that arise in adjacent areas will be bigger than the displacement. The most obvious case, for software, is doing all the things that were previously inefficiencies, but far too expensive to do anything about. Consider any workflow today that is puzzled together by email, Excel-spreadsheets, or people doing repetitive tasks with small variability, but for which the payoff of automation has been lower than the cost of automation.

If the cost of producing software is reduced by just 20%, an immense number of new use-cases suddenly becomes economically viable. If you reduce the cost by 50% or even 90% (unlikely in the foreseeable future), the number of use-cases that can be dealt with has a veritable Cambrian explosion.

Consider previous technological shifts, the things that became economically viable, but this time, add the human intellectual bandwidth which is freed by AI, and we might see a boom the like of which we’ve never seen before.

Doing things that were too big or speculative before

On the opposite end of the status quo, endeavors that were previously too big, too resource intensive, or simply too speculative, become less so. This is the realm of the unknown unknows: new technologies that may seem like science fiction by our current standards.

If the timeline, resources, and cost of a moonshot-type project is reduced significantly, it becomes less of a moonshot, and, more feasible to start in the first place. The impact on this for technology, medicine, biotechnology and other deep-tech industries should not be underestimated. Be prepared for our impending sci-fi future.

Conclusion: humans will be more in demand, not less

Steve Jobs is attributed with the saying that “Personal computers are like bicycles for the mind”.

If that is the case, AI is like a personal rocketship for your brain: It shortens the path from idea to proven or disproven hypothesis. It reduces the drudgery in f’in around and finding out, so that we may find out sooner. Our intellect gets an amazing leverage in thinking about the big picture, while not having to memorize trivia to achieve the same outcome, when trivia with instant recall is at our fingertips.

This in turn, unlocks economic opportunities, small and massive, which are far greater than the opportunities we have today. The consequence is, the world will have a never ending demand for intelligence, both artificial and biological.

Fever dreams of having AI write all our complex software for us are still largely that, fever dreams.

But used correctly, it’s still a powerful tool to get more done, with fewer defects. My use has evolved with time, and my first steps were much the same as everyone else:

First steps: Copilot completion & “fix this!”

Like most others, my first steps were paying for Github Copilot, and asking ChatGPT, and later Claude general questions about code sticking points and algorithms.

The first gains were, for a former RSI sufferer, welcome: it simply made me type less. Github Copilots early in-editor support is autocompletion on steroids, nothing more, nothing less.

Also, having an interactive search like ChatGPT to quickly get personalised responses to what in the past would have been a Google search for a StackOverflow result, is great. We have StackOverflow on steroids!

The big win with the first iteration of tools was less typing, less spending time completely stuck on things of trivia.

Second steps: Contextual help

The next generation has been tools like Cursor, Avante, Cody, and further iterations of Github Copilot - these live in your IDE or editor of choice, and can take a snippet of code, whole file, set of files or whole project as context, and give you help in writing code, writing tests or solving issues like finding the unbalanced brace or other syntactical issues.

I too went through this phase. It’s like having an over-eager junior developer you’re pairing with, who knows algorithms and API’s better than you, but couldn’t see the forest for the trees, if their virtual life depended on it.

At this point, we are writing even less code, but we need a firm hand to drive our virtual junior colleague. They easily miss context, get stuck in loops, or simply cannot solve problems that require more than a few pieces of context in your head at the same time.

We’re not getting replaced anytime soon, the only thing that is happening is that the nature of how we do our job is changing: we are becoming supervisors, while the minutae of typing is becoming less important.

Where I am today: my virtual pairing partner

I am still using AI in all of the aforementioned ways, but I’ve found a few additional use-cases, that really unlocked additional productivity..

I provide the AI assistant with context (usually a few files at a time), constraints, and requirements, and ask it to:

• Find issues with my code: ask if it achieves the given aim, and if there are any issues, smells or edge-cases I can’t see.

• Suggest improvements: Are there ways in which the code can be improved? If there are, I will usually provide additional context, and ask for specific improvement suggestions in the areas highlighted.

• Explain to me what this code does: In the case of code, I am not familiar with, but can explain what it is part of.

• Explain third-party API behaviors: especially useful with systems that are stateful. Most APIs are pretty sucky. But widely used APIs are at least well enough documented and discussed for AI to have been trained on its foibles.

• Ask outright whether specific edge-cases I can envision are covered by a piece of code.

• Look at my tests and my code, analyze whether the tests are comprehensive, or if there are further edge-cases I have missed.

• Verify my SQL is syntactically correct for the dialect I am using, and ensure it is efficient.

• ..and yes, for relatively trivial, but typing intensive tasks, I frequently let the AI generate the code for me. But beware, it’s fraught with issues for anything that goes beyond trivial, which barely makes it worthwhile.

Basically, I have started using AI (I use Cody with Claude as my primary assistant these days) like a pair programming partner, whom I ask the questions I would ask a human pair. With the exception that Claude/Cody never gets tired, never switches off, has amazing recall of API specifics, but can’t see the big picture very well.

The main takeaway for me is, Pair Programming has always been an effective way to review and improve code. While AI assistants are not yet anywhere near human level, they nonetheless provide a valuable second pair of “eyes” to review ongoing work, if prompted correctly.

Conclusions

Software engineering as a profession isn’t going away anytime soon. But it is evolving at a rapid pace, and we need to keep adapting. Adopt, adapt, or become irrelevant.

So far, I wouldn’t say AI is making me hyper-productive compared to my 2022 self, but it is certainly adding 10-20% at least. At the same time, used correctly, I think, rather than generating “AI slop”, we can leverage AI to make our co-created software more reliable, by asking the right questions, and critically taking in the input.

And I’m sure if you ask me again in 18 months, my use will have further evolved.

I’ve seen many discussions on LinkedIn and social media lately on whether a CTO should be hands-on. Opinions differ, but mine is pretty clear:

I’m going to set out my stall early: most early-stage startup CTO’s aren’t CTO’s. Most early-stage startups patently do not need a CTO.

If your CTO writes production code, he probably isn’t a CTO. If your CTO directly manages developers, he most likely isn’t a CTO.

What companies at this sort of scale need, and frequently have, are strong Individual Contributors (“IC’s”), with a good feel for product, who can help teams self-organize and select the correct trade-offs to get to market/iterate after market entry.

But giving these individuals premature titles of CTO, Director/VP/Head of Engineering or similar is doing them a great disservice - if their comfort zone and zone of excellence is the intersection of IC, team & product, asking them to do the work of an actual CTO/Director/VP/Head later will at best make them miserable, at worst have them be awful at their job, when they used to be an outstanding IC & team multiplier.

A star IC & CTO are not the same

A real CTO’s job mostly includes responsibilities far away from writing code: it’s turning the CEO’s business strategy into technological strategy. It’s selecting and negotiating with vendors. Budgeting. Figuring out how to structure the engineering organization, and what that means in terms of the lieutenants they need in place to delegate to. It’s a million things miles away from writing code.

It is also about learning to let go and trust people to do what they were hired to do. Many a star IC over-promoted has a hard time letting go of being an IC, being in control and knowing every minute detail of what is going on in their tech stack. It easily spills over into micromanagement, second guessing and directing people instead of giving them a goal to aim for.

This sort of behavior in a CTO role is absolutely toxic: it makes people second guess what the CTO wants, it sucks the air out of the room, and subsequently robs people of both initiative, agency and growth opportunities.

Seniority means guarding your opinions

It’s lonely at the top. Or at least, it sadly should be:

The more senior the formal title and authority, the more weight even throwaway comments carry among staff. Even without intent, subordinates easily fall into guessing games about what the CTO wants, if they seemed to express an opinion on something. It’s easy for people to fall into seeking approval of a the CTO rather than doing what’s right for their business area.

In practice, this means someone with a senior management title often needs to be well-guarded in expressing opinions publicly in areas which are not their direct purview. It’s better to say nothing, than to send a team into tail-chasing mode because you expressed a preference for one architectural style, technology or vendor over another.

Let’s be honest: being this level of guarded does not come naturally to many people at all. Especially not those who have been on a career-path to seniority. But some excel at it naturally, others learn it the hard way. Yet others never learn, and as a consequence, unwittingly struggle with the issues that it produces.

Early-stage startups and small businesses don’t need a CTO!

I implied early on that most CTO’s of early-stage startups and small companies aren’t CTO’s.

If we take a step back, it’s really no criticism of the individuals who still hold the title. It’s just that what early-stage and small businesses need aren’t a CTO. Arguably, they don’t need Directors, VPs etc. either, they barely need Engineering Managers.

But because CxO titles are cool, and most feel someone needs it, they are handed out like candies anyway, when what is needed is actually something entirely different.

An early-stage startup CTO probably more does the equivalent job of what in a bigger company a Principal- or Staff Engineer does, with explicit final say in technical decisions.

All the inflated title achieves is future prestige & political issues, as demoting someone unsuited to the role is both more frequent, and more infected, than simply not having the title to begin with and hiring for it later as growth requires it.

Occasionally, a company might get lucky, and their designated CTO is actually an appropriate pick and grows with the role. But I’d venture a guess that it is far more common that star Individual Contributors get over-promoted based on showing excellence in areas entirely unrelated to what is required of a CTO. In a way, it’s a tragedy in its own right: you are robbing an individual of the thing they excel at (and often fulfils them), and hanging them out to dry, doing work they are potentially not suited to. They may even cling on to the work of their old role, holding a senior title, but actually doing none of the work it entails.

Take-away: resist title-inflation

Let’s be honest: a 3-5 man company does not need to have 3-5 CxO’s. One is plenty, often to a considerably larger size.

Call roles what they are, and hire for what they are. If the role entails primarily engineering work, the person is an engineer, end of story.

Excessive title inflation will only cause problems of hurt egos as a company grows and people are painted into corners because of the titles they were given prematurely.

Avoiding title inflation is in everyone’s best interest: the company, and the individuals who would be saddled with inflated titles.

This has been further solidified by skills for the three specific clouds being in-demand: a combination of Resumé Driven Development, and certifications have reinforced the loop of moving to the Hyperscalers.

However, lately this default is coming under attack: Amazon Web Services margins, as of April 2024, were 37.6%, quite rich for a supposed commodity business. GCP and Azure margins aren’t far behind. People have started questioning the default, Basecamp have loudly moved from the cloud back to on-premises due to costs.

And even by what can be observed externally, it seems the Hyperscalers are milking their customers. As an example, in a recent price comparison, 50TB of data costs:

• $56 on Hetzner

• $4250 on Google Cloud

• $4350 on Azure

• $4500 on AWS

There are two observations I can make from this:

The Hyperscalers price bandwidth almost 80x higher than some of their smaller competitors.

Secondly, the Hyperscalers usurious egress pricing is curiously closely clustered together to make me think…

But surely there are benefits to the Hyperscalers?

Yes, the Hyperscalers have certain benefits (note: i distinguish between the cloud and hyperscalers, they are not the same).
Not least:

• Close to limitless elastic scaling.

• Global reach - the ability to put compute close to users almost anywhere on the planet. This significantly reduces latency in many cases.

• Global resilience - the ability to create systems where losing an entire datacenter is only a blip.

• A plethora of managed services that reduce the need for dedicated DevOps/systems administrator headcount.

There are surely more benefits that slip my mind at this point, but nonetheless, for organizations that need one or more of the above, Hyperscalers are close to the only game in town.

Do you need it, though?

However, ask yourself, apart from the cool-points you score from saying your system is globally resilient and distributed, can scale infinitely, etc, do you really need those things?

Is your load-profile mostly stable, or perhaps not stable, but predictable, to the point where growth and even best/worst-case scenarios of load are easily achieved with.. Some servers?

Maybe, it’s a case of YAGNI (“You Aren’t Gonna Need It”)? Maybe one of the smaller, budget cloud providers will serve you just as well, for a fraction of the price?

Or if you are a bigger company, perhaps on-premise/dedicated hardware in someone’s datacenter(s) will do the job?

For the third time: consider your defaults!

For the third time in this series of posts, I’m going to make the point I have been making throughout:

Stop defaulting your choices. Start considering the trade-offs of different choices. Pick the best one.

I’m not quite advocating a return to on-premise (though it might be appropriate for some), just consider whether the benefits of the Hyperscalers really apply to your use of compute, and whether they warrant the steep premium paid.

By simply asking the questions and considering the answers, it’s possible you may cut your operational costs down to a fraction. If you compound the choice of not always building microservices, and not always defaulting to the big, expensive cloud providers, the savings could be immense. Simpler architecture leads to less compute being used, and less DevOps work needed. Less compute, from less expensive providers, will improve the bottom-line even further.

As we close the books on the excesses of the ZIRP (“Zero Interest Rate Policy”)-era, it’s worth reflecting on the excesses our industry got caught up in. Expensive default choices are definitely some of them.

Previous entries in this series:

• Old school architectures making a return, part 1: Monoliths

• Old school architectures making a return, part 2: Backend rendered webapps

The last 15 years has seen us move from backend-rendered webapps to Single-Page-Applications (“SPA”), to hybrid approaches like Next.js and Remix.

In the 2000’s, most webapps were simple backend-rendered things, usually following a Model-View-Controller pattern. When Gmail arrived on the scene, everyone got excited about how Google had managed to make a webapp so dynamic and desktop-app like. What followed was the evolution that led us to modern SPA web-frameworks like Vue and React, where eventually, frontends are in effect their own applications, talking to a server, usually via a JSON-over-REST API.

As a one-size-fits-all approach has been found wanting, we have also had novel new approaches, like the hybrid frontend frameworks like Next.js, Remix & Nuxt, where pages are sometimes rendered on the backend, sometimes on the frontend.

The benefits of SPA and hybrid SPA/SSR apps

Pushing logic to the client’s browser is not without merit. In a pure SPA approach, an app can be distributed via CDN, and a lot of logic can be executed locally in the client’s browser. This frequently gives the perception of a faster app to end-users.

A hybrid SPA/SSR (“Server-Side Rendered”) app achieves similar goals, while allowing certain necessary aspects to be done on the server-side, and also improving the ability to Search Engine Optimize content.

Yet another benefit is that you frequently get an API for your backend “for free”, that other clients, internal or third-party, can also use. However, as we’ll soon discuss, “free” things are rarely actually free, they come at a cost.

A final benefit of modern web frameworks in particular, is that they have adopted a component-based approach: this frequently means it's easy to re-use frontend components across the application, or even across applications.

The drawbacks of SPA & SPA/SSR hybrids

The SPA & hybrid approaches come with quite a few issues, let’s have a look at some of them:

The “free” API duplicates work

With a separate frontend and backend, communicating via an API comes a cost: duplication. Frequently user logic, flows and validation are duplicated across both. In bad cases, the responsibilities get muddled, perhaps too much logic gets pushed to the frontend, exposing security weaknesses in the backend.

I’d estimate (completely made up, but plausible based on anecdotal experience), a strict frontend/backend split results in between 40-80% more work compared to just a simple backend rendered app.

The API is frequently unsuited for other clients

The “Backend-for-frontend” pattern is a tacit admission that different clients require slightly different API’s. This means that the API designed for a webapp, will rarely be well-suited for a mobile app, or some headless automation. In practice, you’ll either end up with suboptimal interaction patterns to your API, or multiple API’s tailored for different clients.

The “free” API you got with your webapp gave you nothing but extra effort. Even where the API fits, clients are likely to only need some small subset of the API.

Testing becomes challenging

Testing is hard as it is. With effectively separate apps, testing just got even harder. Instead of just writing unit/integration tests with something like test-containers and an embedded web-server, testing the entire app end-to-end, you need to either fake the backend, risking drift in your fakes from the real behavior, or deploy the entire stack, and write flaky end-to-end tests, that take long to run, are difficult to write, easily fall apart, and eventually no one pays attention to.

Lost productivity

So if we duplicate work, make testing harder for ourselves, we’ve already damaged our productivity quite significantly, haven’t we?

To add insult to injury, we also have to spend time and energy either finding ways of sharing representations of types, or worse, duplicating them on server and frontend respectively. Even where this is trivial, and assuming we have fullstack developers who do both sides, they still have to jump between codebases potentially, doing mental context switches as they transition between frontend and backend.

SPA/SSR hybrids are difficult to reason about

Why don’t we just use Next.js/Remix/Nuxt/insert-hybrid-framework-here as a full-stack framework? We can use SSR with those?

Well, yes you can. But in my experience, it can be difficult to reason about when exactly something is client-rendered, vs server-rendered. And in the wild, I have seen instances where this has led to passwords and other secrets leaking to clients.

The Next.js approach in particular of having “use client” and “use server” directives are in my opinion, an absolutely horrible approach just waiting to go wrong.

The Solution: an old-school alternative that isn’t entirely old-school

You might have read between the lines that I am about to suggest we go back to writing server-side rendered webapps in your backend language of choice, and you wouldn’t be entirely wrong.

But, there’s a twist:

I don’t think we should throw out the baby with the bathwater. We can still update portions of a page, but instead use tools like HTMX, to build hypermedia driven applications. This allows us to get the best of both worlds: dynamic webapps, swapping out elements of a page, but where the code is cohesively contained in one codebase, for which the execution is easy to reason about and easy to test.

Another part that would get painful in a backend-driven webapp is writing reusable components and design systems. However, for this too, there is a solution: the Web Components standard, that can be implemented with libraries such as Lit.

In other words, with Web Components, there is still a bit of room for “frontend web development” as we know from the last decade, but with a massively cut down scope. And with hypermedia and HTMX, we cut out the unecessary step of constantly turning JSON into HTML.

Not every problem is suited to going back to basics

Of course, the world is full of nuance, problems of varying complexity. There are surely problems that require a very frontend heavy approach to solve. So, as always, consider the trade-offs.

My preference towards backend-rendered webapps leaning on a hypermedia-approach with web components is for the 80% of webapps that are below the complexity threshold where something else is necessary.

There are no blanket solutions, merely trade-offs to be weighed. As in the first part of this series of posts, my main recommendation is to stop defaulting and start thinking.

For the majority of apps, there are simpler ways. For some, the dominant approaches of the last decade might be perfect.

Also consider reading:

• Old school architectures making a return, part 1: Monoliths

Cloud native architectures brought about the technical viability of microservices. But what technical problems do they actually solve, and are monolithic architectures more viable under some circumstances?

Let’s answer the first question first:

There are very few technical reasons to use microservices. They are almost always a solution to a people problem: a means to scale an engineering organization without unfeasibly large and unproductive teams. They allow us to split an organization into multiple teams, all owning their own domain or slice of the company’s concerns.

It is no coincidence that microservices rose to prominence during the ZIRP (“Zero Interest Rate Policy”)-era: when Venture Capital was abundant, the capital needed to be used, usually to grow engineering. Growing engineering meant multiple teams needed to be created (we all know how detrimental massive teams are to productivity).

Microservices allows us to solve the problem of organizational growth, it answers the question of how do you split work across multiple teams, when multiple teams become necessary due to workload and headcount growth?

Surely, there are technical merits to microservices?

Yes, I can think of a few technical reasons for splitting into services, apart from organizational growth:

• Independent scaling - you may split services based on read and write boundaries, if one is more performance intensive than the other. This allows us to scale services independently.

• Observability - if you are at the top of your observability game (very few are!), the smaller functional surface of microservices allows us to more easily diagnose issues as they arise.

• Distinct domains - perhaps the most obvious case, some things are simply completely distinct domains, and should be separate. However, experience tells us, that microservices frequently slice adjacent or related domains slightly wrong.

What are the issues with microservices?

Microservices come with several drawbacks:

• Observability is challenging - I mentioned this as a benefit, but it is also a drawback. Very few organizations have the observability and ops maturity to pull off microservices.

• Cascading reliability & coupling - many organizations set reliability goals, such as “99.9% uptime. But what happens if services are coupled, and multiple services with the same reliability goal need each other? Simple arithmetic dictates that the reliability goal becomes impossible to achieve: 0.999*0.999*.999 is less than 99.9%.

• Poor industry understanding of asynchronous interaction patterns - leading on from the previous point: ideally, microservices should prefer asynchronous communication as much as possible, so they survive downtime of adjacent services. In practice though, people frequently implement synchronous RPC or REST interfaces, thus increasing coupling and overall system fragility. This is often done in the name of “simplicity”, simply because there is insufficient understanding and appreciation of asynchronous communication.

• API impedance mismatches, performance issues & fragility - What one service provides to another does frequently not line up with what the user requires. This might lead to n+1 interaction patterns or worse (I’ve seen bulk downloads hammer services!). Not only that, but services must also consider API versioning and how changes may be breaking. It’s not uncommon to see breakages because some API or protocol was changed unilaterally, without thought to communicate changes and plan a migration path.

• Lowered productivity - should come as no surprise that all of the above contribute to lower productivity, compared to working in a monolithic codebase. Even if under the control of a single team or empowered to make changes in adjacent services, working on multiple codebases across network boundaries is slower.

Are monoliths the answer?

Maybe, sometimes, it depends. Monoliths certainly address most of the issues effectively, and reduce the need for excellence in ops and observability.

One issue of the last decade is that too many organizations have defaulted to microservices without considering why they are doing so. Simply considering why you are choosing microservices, whether it is appropriate given the technical- and productivity costs in the light of your company’s engineering org growth plans. If headcount is likely to remain relatively static, or only grow slowly at times, maybe a monolithic architecture makes more sense.

In conclusion, I think we’ll see a return to more organizations defaulting to monoliths instead of microservices. There is no one-size-fits-all answer to the question of monoliths vs microservices, but moving from an unthinking default, to a considered decision given a set of trade-offs will naturally see monoliths becoming more popular again.

Stay tuned!

This post is part 1 of a four part series on old architectures becoming new again. I will post the next part next week, so if you want to read it first, please do sign up to the newsletter!

I have used almost exclusively Macs since about 2007, but had my first Linux desktop in the late 1990’ies while at university.

I have owned a Linux desktop since 2018, which mostly acted as a server, and last year I bought a monster desktop with an AMD 7950X3D processor, 64gb RAM and Nvidia 4090.

Today, I only pick up my M1 Max Macbook Pro when circumstances dictate I need a laptop, otherwise, I mostly use my desktop. But for a long time after my desktop purchase, I was still using the Mac as my primary computer. The switch-over really only happened fully in the last 3 months or so.

Dipping my toes in

The desktop came with Windows 11 installed. It lasted about 4 hours before I could not stand it. Back at the end of last year, I installed Pop!OS on it, simply because it was the one distro I could make work with the Nvidia card.

A year later, the picture has changed a lot: I’ve since tried Ubuntu (24.04 and 24.10), Kubuntu, Pop!OS and EndeavourOS (an Arch based distro with simple GUI installer). All of them install easily, without much pain.

However, for the first 9 months, I didn’t fully go Linux, I used the desktop for some work, and some games, but tended to prefer my Mac still, purely out of habit. Slowly, that picture changed, and about 3 months ago, I went on Linux-Distro safari, tried all of the aforementioned Linux distributions.

Now, I think I’ll probably stick Linux, and I’m pretty sure my next laptop will be a Framework 13, assuming Framework start shipping to Switzerland. I wouldn’t expect a non-Mac to have the build-quality or battery life of a Mac, but then again, a new top-end mac would set me back about $5000, whereas a fully-kitted out Framework 13 would be < $2000. The Mac will certainly not be 2.5x better than a Framework.

The reality of Linux vs Mac OS

After a year of going back and forth, my take on Linux vs Mac OS is: there’s really not much between them. I don’t think one of them is particularly better than the other. If you know how to use a computer, the transition will be mostly smooth, and almost all the same apps are available in one shape or another, or at least analogues are.

What brings me to Linux is a few things:

• I like to develop software on the same platform I deploy to. Least risk of weird bugs.

• There really isn’t much difference. Apart from Command vs Control key usage for copy-paste, I can move seamlessly between the platforms. Maybe a testament to how far Linux has come, is that I can’t say it’s worse than Mac anymore. Things mostly just work.

• I like to foster vendor-independence in my workflows. Being bound to a single eco-system sits wrong with me. So being able to move between platforms just feels good. Call it compute-autonomy.

• I really can’t bring myself to pay 2-4x for the same hardware, when the experience isn’t even 10% better. As an example: a 1 to 4tb SSD upgrade with Apple is about $1100. You can buy some of the top-of-the-line 4tb SSDs for PC’s for under $300. I promise, the soldered, unrepairable stuff is not 3.5x better.

Where Linux is better: Gaming

The work that Valve has put into Proton and the Linux platform is nothing short of amazing. Gaming is perhaps more of an aspirational hobby for me, than a real one, but it seems to me that practically every single-player game ever made for PC plays well on Linux now, with few exceptions.

The area where gamers might encounter issues is multi-player games, where anticheat systems rely on Windows rootkits, but this is not an issue for me, as I don’t really play multiplayer games.

What about window managers?

I have tried Gnome, KDE, i3wm and Hyperland.

If you want to keep it simple, not tinker, and have things just work out of the box, just stick to Gnome or KDE. Anything else is asking for initial pain.

I’d say Gnome feels familiar for a Mac user, KDE feels familiar to Windows users. KDE though has higher ability of customize the look-and-feel, and the default apps of the KDE eco-system have slightly better polish.

If you care about polish and customizability, go KDE. If you want to keep things simple, go Gnome.

Personally, I did not keep it simple: I prefer using Hyprland, a tiling window manager as my default, which I’ve heavily customized for my needs (see screenshot). I did this, because I simply like the workflow where I can keep my hands on the keyboard most of the time, and very rarely have to use the mouse. But It wouldn’t recommend it if you are not prepared to put in the time. I use KDE as my backup, and I also use the KDE apps as my default apps for file-management, PDF viewing etc.

Which distro should I pick?

Again, if you want a simple life, where everything just works: use a Ubuntu LTS for Gnome, (currently 24.04), or the Kubuntu LTS for KDE. I suspect vanilla Ubuntu might be the best tested one. Everything should just work, including sleep etc, unless you have new, unsupported hardware.

If you feel adventurous, go with a non-LTS Ubuntu/Kubuntu. It’s worth noting, a lot of “big software vendor” software is frequently built and tested for Ubuntus LTS releases, so if you rely on some specific software, Ubuntu LTS will be the path of least resistance.

Obviously, I don’t heed my own advice, and instead went with Endeavour OS, which is an Arch Linux based distribution. This means occassionally some things break, sleep doesn’t work etc. But this is pain I’ve imposed upon myself in exchange to have the latest and greatest software for everything. Can’t be a beta-tester without experiencing some bugs, huh?

Should I switch from Mac to Linux too?

My advice here is: really depends. Like I’ve said, there isn’t much between Mac and Linux for a software engineer these days, the experience is very similar, UX, hardware support, software, all within 10% of each other.

For me, the question comes primarily down to autonomy/independence, using open source, and ultimately, not seeing the point in paying usurious Apple prices anymore, when I can get similar quality for a third of the price. Sure, I won’t expect exact equality in quality, but it’s good enough to not warrant a 3x markup.

Also, given how resource-light Linux is, I’d expect hardware to last much longer. As an example: I recently gave my mother an old 2014 Macbook Pro. It is out of support for MacOS updates, but Ubuntu 24.04 ran merrily on it when I installed it. Lifespan extended by yet another few years (Apple typically support computer hardware for up to 7 years).

If you are looking to switch, Linux likely won’t rock your world, but neither will it diminish your quality of life and work. In 2024, Linux mostly just works, is as usable as Mac or Windows (probably more so than Windows!), and has sufficient software to get almost anything done.

If you’re a gamer, whether casual or hardcore, chances are also that Linux will be the best possible platform for you.