Dreaming a Future of Software Engineering
Dreaming a Future of Software Engineering
Imagining how to improve the software production process by making good use of AI, and thus how to make better software
2025-12-23
Why talk about this
To dream similar dreams with colleagues
To get feedback and revise the dream
Timeframe
Between now and the near future: Until AI completely takes over software creation, what are we going to do? ← This is the point in time
Distant future (hopeful version): AI + robots take charge of all labor and production, distribution becomes just, and people live happily while pursuing their own values.
Distant future (despair version): Omitted
Premise
Everyone is trying to maximize productivity by using AI. Not participating in this game is not a good strategy.
If we’re going to do it anyway, rather than blindly following along, let’s take the initiative with the aim of changing the world, even a little, in the direction I dream of.
Dreaming?
- ❌ Prophecy, prediction
- ✅ Having something one hopes for and trying to make it happen
Fable
A world where if you enter a search query, the results come out a month later
Imagining is difficult.
The more it is one’s own area of expertise, the more so.
The way one does things now comes to feel natural, and imagination about the possibilities of new technology can be limited.
Software process
Modern software is barbaric.
- Because the problems that need to be solved are not being solved sufficiently
- Because the people participating in the software process (planners, designers, programmers, testers, etc.) are doing work that demands superhuman capability
- Because software is released into the world in an extremely compromised state
- The situation in which people in marginalized situations experience relatively more problems is reproduced and amplified.
What on earth hasn’t been solved? Are we really doing work that demands superhuman capability?
Case 1. Planning or system design
What you write down doesn’t mean exactly what you think it means. And when it does, it doesn’t have the consequences you expected. —Daniel Jackson, Software Abstractions: Logic, Language, and Analysis
The limitations of specifications written in natural language
Case 2. Design
width: 1024px vs. max-inline-size: 60rem
Placing elements on a canvas vs. declaring intent
Attempt 1. Code quality management
Source code quality in the age of AI
Virtuous cycle:
- If you tune the LLM well, you can maintain a good codebase.
- In a good codebase, the LLM produces good code.
Attempt 2. Making it follow best practices
March-April 2025
Agent-based coding experiment 1
Current status + impressions
- It’s really hard to make an LLM do TDD properly (maybe it can do it better now?)
- But why make an LLM do TDD? → Software engineering in the age of AI
Attempt 3. Upfront design, traceability
April-July 2025
- A structured specification based on YAML files
- s4 CLI: a CLI tool that manages context and provides instructions based on that specification
Current status + impressions
- Beneficially relating elements: beneficially connecting humans + code + LLMs
- Stateless AI-human interaction becomes possible
- I don’t like that the specification is described only in natural language, and that the link between the specification and the acceptance tests is weak
- If I made it again, I’d base it on SKILLS.md
Attempt 4. specdown
November 2025-present
- A document mixing Markdown and Alloy code in a Literate programming style
- specdown CLI: a CLI tool that extracts Alloy code from that specification and runs it
- specdown skill: a Claude Code skill that helps with writing the specification incrementally using the above tool
Current status + impressions
- Testing whether it’s actually usable by creating all sorts of specifications. It feels like it’s working 💃🕺
- Trying to generate test cases from the model of the specification
Caution
Heavy harness + Galápagos
- Reduce the harness (including Markdown)
- Bring in and use decent tools that lots of other people use