ewernli

Stop Writing Code: The Copilot Challenge

What if the best way to master Copilot… was to stop writing code yourself?

Seriously. For one week, try this: don’t type a single line of code manually. Not a function, not a fix, not even a variable rename. Use only Copilot’s edit panel or inline chat. Prompt it. Guide it. Iterate with it until it gives you exactly what you want.

At first, it’ll feel terrible. You’ll see a bug and want to just fix it. You’ll want to write the obvious helper function. You’ll feel slower. But that discomfort is exactly what makes this powerful. It forces you to get better at communicating with Copilot. You have to break down problems into clear steps. You have to give proper context. You have to think like a teacher, not just a doer.

And without even realizing it, your coding style starts to shift. You begin naming things more clearly so you can refer to them easily in prompts. You start structuring logic in ways that are easier to explain and reuse. Just like writing testable code improves architecture, writing code that’s “promptable” improves clarity and design. You’re not just optimizing for the machine — you’re learning to write code that explains itself.

You can still use inline chat to nudge Copilot: “Add a loop that groups items by category.” You can even dictate code word-for-word if you really want to. But that’s tedious, and you’ll quickly realize it’s easier to just get better at prompting.

This constraint becomes a force function. You stop relying on your muscle memory and start building Copilot fluency. You learn when to rephrase, when to simplify, when to break things down smaller. And as you do, you become dramatically more productive — not just faster, but more thoughtful.

Now imagine turning this into a game. A leaderboard that says “It’s been 6 days since I last wrote a line of code myself.” Friendly team competition. Badges like “100% Copilot PR” or “Zero Typing Tuesday.” A culture shift that makes learning fun — and a little bit addictive.

This isn’t about replacing developers. It’s about training ourselves to think differently. To move from writing code to shaping it. To go from typing to directing. And in the process, to write code that’s not just correct — but clear, composable, and ready for collaboration with humans and machines alike.

So give it a shot. No code writing. Just Copilot. See how far you can go — and what you learn along the way.

Climbing the Abstraction Ladder with LLMs

Software engineering has always been about raising the level of abstraction.

We started with assembly language, then moved to procedural programming (Pascal), followed by structured programming (C). Object-oriented programming (C++) introduced encapsulation, while managed memory (Smalltalk) improved reliability. Later, portability became a focus with language runtimes like Java and C#.

This progression has been captured through the concept of programming language generations—1st, 2nd, 3rd, 4th, and 5th generations. The 4th generation was envisioned as a major shift: instead of manually managing implementation details like data structures and persistence, developers would write high-level specifications, and the language or environment would handle the rest. The 5th generation would rely on automated problem-solving. However, despite various attempts, mainstream programming remains at the 3rd generation, and 4th- or 5th-generation programming has yet to materialize—until now.

Large language models (LLMs) might be the first real step toward achieving this vision. For the first time, we can provide human-level specifications and let an AI generate working code. LLMs attempt to resolve ambiguities and infer intent—something they do surprisingly well. Interestingly, generating code that strictly adheres to a precise specification might turn to become the challenge.

Right now, with tools like Copilot, we use LLMs “in the small” to generate local sections of code. But what happens when we use them “in the large”—to generate most of a system? We may soon be able to integrate architecture documentation, business specifications, and UX mockups to produce functional software, but how such documentation should be structured remains an open question. As a colleague once put it, we will need an entirely new “theory of software documentation” for the age of LLMs.

This shift also echoes some of the ideas behind literate programming, introduced by Donald Knuth, which aimed to make code more readable by structuring it like natural language text. Throughout the history of software engineering, the primary medium for expressing and evolving programs has been text. LLMs, trained on vast amounts of textual data, take this evolution to its next logical step, blurring the lines between documentation and implementation.

Between small-scale and large-scale code generation, one particularly interesting application of LLMs is refactoring. Automating local modifications across large codebases has traditionally been handled by tools like OpenRewrite. However, writing precise transformation rules is tedious. Given LLMs’ ability to extrapolate from examples, they seem promising in the area.

With large-scale code generation, it’s still unclear how much of our code will be AI-generated in the future, and how much will require manual intervention. Also, it’s unclear how we will we manage and distinguish between the two. Traditional methods rely on inheritance or annotations to link generated and manually written code. LLMs, however, are not bound by these constraints. They can generate, rework, or extend code seamlessly. This isn’t just a technical problem but a methodological one.

The foundations—both technical and methodological—for engineering software with LLMs are still being developed. The best way forward is through experimentation and collective learning. The software industry is already embarking on this journey, and it’s exciting to be part of such a profound shift.

Talk: Inside SAFe Principle #1 (@SBB DevDay’24)

I gave a talk a the yearly SBB DevDay conference. It was about SAFe’s principle #1: Take an economic view. The main idea was to compare the economics of software development with the economics of manufacturing to better understand concepts like capex, opex, maintainance, debts.

https://www.slideshare.net/slideshow/inside-safe-s-principle-1-take-an-economic-view/272378146

Understanding ChatGPT

ChatGPT has surprised everyone. We now have systems that produce human-like texts. Without much fanfare, ChatGPT actually passed the Turing test.

While we don’t fully comprehend how and why large language models work so well, they do. Even if we don’t fully understand them, it’s worth building an intuition about how they function. This helps avoid misunderstandings about their capabilities.

In essence, ChatGPT is a system that learns from millions of texts to predict sentences. If you start a sentence, it tries to predict the next word. Taking the sentence augmented with one word, it tries again to predict the next word. This way, word after word, it can complete sentences or write whole paragraphs.

Interestingly, the best results are achieved when introducing randomness in the process. Instead of always selecting the most probable word each time, it’s best to sometimes pick alternatives with lower probabilities. It makes the sentences more interesting and less redundant.

What’s also kind of amazing is that this approach works to answer questions. If you start with a question, it tries to predict a reasonable answer.

Thinking of ChatGPT as a text predictor is useful, but it’s even more useful to think of it as a form of compression. When neural networks learn from examples, they try to identify regularities and extract recurring features. The learning is lossy: the neural network doesn’t remember the examples it was fed with exactly. But it remembers the key features of them. When ChatGPT generates text, it “interpolates” between the features.

Impressive examples of “interpolation” are prompts that mandate an answer “in the style of,” for instance, “in the style of a poem.” ChatGPT not only gives a coherent answer content-wise but also applies a given style.

But ChatGPT is, in essence, interpolating all the time. It’s like a clever student who didn’t study a topic for the course but has access to the course material during the exam. The student may copy-paste elements of the answer and tweak the text to sound plausible, without having any real understanding of the matter.

What ChatGPT shows us is that you can go very far without a true understanding of anything. And I believe that this applies to how we behave too. On many topics, we can discuss based on facts we heard, without actually understanding the underlying topic. Many people who sound smart are very good at regurgitating things they learned somewhere. They wouldn’t necessarily be particularly good at reasoning on a topic from first principles. To a certain degree, we conflate memory with intelligence.

At the same time, ChatGPT can do some reasoning, at least some simple one. It probably has extracted some feature that captures some logic. It works for simple things like basic arithmetic. But it fails when things become more complicated.

Fundamentally, when predicting the next word, ChatGPT is doing one pass of the neural network, which is actually one function. A pass of the neural network cannot do a proper computation that would involve, for instance, a loop. It fails the prompt “Starting with 50, double the number 4 times. Do not write intermediate text, only the end result.”, giving 400 back. But asked to write the intermediate steps, it computes correctly 800. You can help ChatGPT into multi-step computation by asking him to write the intermediate steps because then it will go through the neural net several times. This pattern is known as “chain of thought prompting.”

We don’t fully understand ChatGPT yet—how it works and what it really can do. But clearly, it can do more than we expected, and it will bring all kinds of exciting insights about cognition.

References:

What is Apple?

Apple has grown into a fascinating company with a diverse range of offerings. Initially known for its computers, it has expanded into various industries. With Apple being the most valuable company in the world according to its market capitalization, it’s worth asking: what is actually Apple now?

It’s a fashion company – Apple has become a fashion staple, with its accessories blending seamlessly into our daily lives. We don’t just use Apple products; we wear them (EarPod, iPhone).

It’s a luxury company – Apple’s products command a premium price tag, appealing to consumers seeking quality and prestige. Interestingly, both the affluent and the everyday consumer use Apple products.

It’s a technology company – At its core, Apple remains a technology powerhouse, continuously pushing the boundaries of innovation with advancements like the M1 chip or VisionPro, a testament to its ongoing commitment to cutting-edge design and functionality.

It’s an entertainment company – Venturing into entertainment with Apple TV and original content production, Apple has diversified its portfolio beyond hardware alone.

It’s a finance company – Apple has financial services like the Apple Store and Apple Pay, showing its ambition to capitalize on its robust market presence. Apple is becoming a bank more and more.

So basically, Apple does a bit of everything, which is pretty interesting!

While many of these products were launched under the leadership of Steve Jobs, others have been initiated under the stewardship of Tim Cook. Cook may not have spearheaded groundbreaking innovations like the iPhone, but his management has propelled Apple to new heights.

Renowned investor Warren Buffett’s strategy typically avoids technology investments due to their intense competition and difficulties in sustaining lasting competitive edges. Instead, he prefers investments in durable goods and services with robust brand loyalty and high switching costs. The evolution of Apple’s identity is noteworthy, particularly as Buffett began investing in the company. Today, Apple stock comprises a significant 70% of his portfolio, marking a notable departure from his traditional investment approach.

Apple’s story is unique and one thing remains certain: its ability to surprise, inspire, and redefine industries will continue to captivate audiences worldwide.

(Style improved with ChatGPT)

Neuromancer

Amidst all the excitement about AI and the metaverse, I recently decided to dive into Neuromancer, the classic sci-fi novel that sparked the cyberpunk genre.

I’d heard it was a big inspiration for The Matrix, so I was curious to see how they compared. While there are definitely similarities, like the matrix itself and the tough, leather-clad female character, the plot diverges distinctly.

Instead of focusing on freeing humanity from the matrix, the book revolves around jailbreaking an AI and merging it with another AI to create a superintelligence. It kind of reminded me of Transcendence, with its futuristic vibe similar to Blade Runner, which came out around the same time as the book.

The writing style is pretty unique, almost like poetry in places, and the story feels like a wild ride. It’s not the easiest read, but it captures well the crazy journey the characters are on.

One thing that stood out to me was how the book portrays the matrix/cyberspace—it’s abstract and undefined, somewhere between VR and a system for visualizing information, kind of like augmented reality today.

It’s also somewhat ironic is that despite its visionary themes, Neuromancer didn’t foresee wireless communication. The protagonist constantly “jacks in” and “jacks out”, relying on physical cables.

It’s pretty wild to think that this book was written back in 1982, considering it tackles themes like AI and the metaverse that are becoming such big topics in 2024. Apple released its first VR set, AI got mainstream, and discussions about the risks of AI are hotter than ever. Neuromancer’s foresight is pretty impressive, making it a classic worth revisiting.

(Blog post style improved with ChatGPT)

Scarcity is the Mother of Invention

The original proverb is “Necessity is the mother of invention.” But as we explore the ways we innovate, it’s clear that scarcity rather than necessity plays a big role in sparking creativity. Indeed, if you’re in need of something abundant, you won’t be innovative. It’s scarcity that prompts us to think differently and find new ways to solve problems.

Scarcity affects many parts of our lives: from time and labor to energy, food, and attention. Each scarcity challenges us to think creatively and come up with new solutions.

Time is something we all wish we had more of. Anything that helps us save time or use it better becomes really valuable. Tools like ChatGPT make communication and problem-solving faster and easier. And platforms with good content save us from wasting time on things we don’t enjoy.

When there aren’t enough people to do the work, organizations have to find ways to be more productive. Digitalization, for example, helps streamline processes and automate tasks. In fields like transportation – where I’m working – , automation helps deal with staffing shortages, like in traffic dispatching.

Other resources, like energy and attention, are also scarce because we only have so much time and focus to go around. Using energy efficiently saves us money and time, while managing attention effectively helps us stay focused on what’s important.

When resources are scarce, we naturally start looking for other options. We switch from human to machine labor, look for renewable energy sources, find sustainable food options, and use technology to help manage our attention better.

While necessity might kickstart our creativity, it’s scarcity that really pushes us to innovate.

(The style of the blog post has been improved with ChatGPT, of course)

Working with AI – A First Experiment

AI will be in an inevitable tool to use in the future. To get a first impression of how it is to work with AI, I decide to realized a very small project using ChatGPT as assistant.

The small project would be a webpage that charts the performance of a portfolio of stocks. I haven’t written webpages since a long time (15 years!), so I would have to catch up using ChatGPT. I also decided to explore AWS Lambda at the same time.

The architecture is very simple: The webpage is a static file and historic stock quotes are stored on AWS S3. There’s a lambda that fetches the stocks quotes every night and stores the output in S3. The computation of the portfolio is done on the client-side. The key to access the stocks API is therefore not public, and I also don’t need a real backend to serve data.

For charting, ChatGPT suggested Chart.js, which was fine. For the stock API, the suggestions of ChatGPT were less useful. I had to compare myself the various sites directly. Finally, I settled on marketstack. That’s the best free tier I could find. Unfortunately, it doesn’t provide an API for currency rate. For hosting, ChatGPT gave me handing hint: you can upload you static website on AWS S3 and make it publicly accessible.

With the help of ChatGPT, it took my a couple hours to build the first version of the webpage using Chart.js and pure javascript.

Key learnings:

AI productivity boost is real. ChatGPT is quite amazing. It can give good suggestions about technological options. The quality of the code is also surprisingly good. You need to double check the answers, but it provides a lot of good insights. Definitively a productivity boost.
Good onboarding experience helps win clients. There are many stocks API. The quality of the various stocks API differ a lot. Onboarding is a killer point for any technical product. I chose marketstack because it was the simplest option to get something working, even though I know it doesn’t have a currency API which I will need later on.
Domain knowledge is always an asset. As with most business domain, things are never as simple as they seem. Computing the performance of a portfolio seems a no brainer. But stocks can split and have dividends. Therefore, the nominal historic price is misleading for long-term historical analysis. Instead, APIs provide adjusted closing prices.
Designing framework APIs is an art. There are many charting libraries and the way they are designed differ a lot. This reminded my of Why a Calendar App is a Great Design Exercise. Designing a chart API would a great exercise, too.

As for the webpage, I see lots of way to improve it further. From the domain point of view, I could add support for comparison with various indexes. From the technical point of view, being able to edit the portfolio would be nice. Supporting several users with login would also be a nice experiment. Figuring out what a delivery pipeline for lambda look like would also be interesting. At the moment, it was all manual uploads to S3.

If I have enough time, I may continue the project with ChatGPT. For the technical points, ChatGPT helps a lot, and proved to be a valuable assistant.

TOGAF: The Good Parts

TOGAF is a framework for enterprise architecture management. Enterprise architecture aims at aligning the business and IT to achieve the strategic goals of the enterprise. Enterprise architecture supports digital transformation in large enterprises.

The core of the TOGAF framework is the architecture development method (ADM).

In a nutshell, the method works as follows:

in the preliminary phase, you build up the enterprise architecture capability itself (that is, you establish and tailor the TOGAF framework)
the architecture work is triggered by architecture changes that go through the whole cycle.
Phase A-D work out the candidate architecture, which is decomposed in four architecture domains: business, application, data, and technology. Application and data architecture are grouped together into “information systems architecture” in the cycle.
The candidate architecture is solution-neutral. Up to this point, you identify changes to business processes, applications, interfaces, data models, platforms without defining a concrete implementation.
A more concrete solution is worked out in phases E and F. The selection of precise technologies, implementation architecture styles (microservices, streaming, etc.), or vendors come especially in these phases.
Phases E and F also cover planning with key stakeholders using an architecture roadmap and migration plan that define the work packages.
In phase G, the project is handed over to the implementation organization (e.g. an agile release train). Expectations about the outcome to deliver and quality are agreed in an “architecture contract” between the architecture and the implementation organization.
Phase H is a retrospective where improvements are formulated and kickstart a new cycle.

The cardinal sin to avoid is to jump from A to G, namely, from the business need to the implementation plan. We’ve all been there: the business has an idea and mandates a team to realize it, without looking left or right and how it would fit in the bigger context. This usually leads to specific solutions for specific problems. Over time, the architecture landscape becomes fragmented and inconsistent. The goal of enterprise architecture is precisely to avoid this. Business needs should be supported by a consistent architecture strategy.

This goal of consistency is supported in TOGAF with the concept of building blocks. The architecture consists of architecture building blocks (business, application, data, or technology) that can be used or reused. In phase B/C/D architects identify which building blocks have to modified, added, or removed for a given change. This is the gap analysis between the baseline and target architecture. In phases E and F, when the concrete solution architecture is worked out, solution architects identify solution building blocks to fulfill the requirements.

Part of TOGAF is also a content metamodel that define key entites to model the four architecture domains (business, application, data, or technology). It’s pretty generic but can be good starting point. You will probably have to refine it though, so that it becomes really useful (e.g. refine the technology metamodel to distinguish between plattform and frameworks).

These core concepts of TOGAF define a useful methodology to tackled complex architecture change. It’s the good parts.

From the perspective of agility, the framework is neither good nor bad. It will all depend on your implementation.

The framework is iterative in nature. Each architecture change goes through the cycle and is an iteration. How big the changes are, how long the cycles last, and how many iterations can run in parallel will depend on your implementation. Part of the preliminary phase is the idea to tailor the framework to your needs. You can implement the core idea in a bureaucratic manner with many deliverables and approvals. But you can also implement the core ideas in a lightweight manner with a few well chosen checkpoints. Similarly, you can partition the enterprise architecture work in “segments”. What they are and how big they are will depend on your implementation.

The bad parts of the framework are the useless ornaments around the core concepts. I can make a list:

The many deliverables expected to be produced along the cycle. I like the core concepts as long as they remain concepts. But TOGAF also defines a set of deliverables that probably are never implemented as such.
The template library documents predefined viewpoints that can be use to document the architecture. This level of details is mostly useless.
The content metamodel comes with two additional references architectures to model the technology and application domains. This complexifies the discussion about modelling without bring much benefits.
The framework comes with a set of techniques that can be employed to carry out the phases. What has been defined as technique or not seem rather arbitrary. The techniques can serve as inspiration to conduct real work, but I doubt they will be followed as such.
The framework defines a classification scheme for building blocks, ranging from generic to enterprise-specific, called the enterprise continuum. The value of the continuum as concept and its applicability are rather unclear.

These ornaments make the framework bigger with details, without being practical enough to be really useful. They mostly distract rather than help.

Talk: Centralized/Decentralized (@SBB DevDay’22)

Each year, I try to give a talk at the internal SBB Developer Conference, called “SBB DevDay”). The previous years, I gave talks about concrete technology challenges. This year I tried something new and gave a talk about development methods and practices.

I consolidated my experience and insights of the past 6 year as lead architect into a useful framework to think about software architecture governance. This perspective mixes traditional agile concepts with concepts of choice architecture.

DevDay 2022.pptx from ErwannWernli