# Dreaming a Future of Software Engineering > ## 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 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](https://wiki.g15e.com/en/pages/When%20Searches%20Take%20a%20Month.txt) 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. 1. Because the problems that need to be solved are not being solved sufficiently 2. Because the people participating in the software process (planners, designers, programmers, testers, etc.) are doing work that demands superhuman capability 3. Because software is released into the world in an extremely compromised state 4. The situation in which [people in marginalized situations](https://wiki.g15e.com/pages/Marginalized%20groups.txt) 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. --, [Software Abstractions: Logic, Language, and Analysis](https://wiki.g15e.com/pages/Software%20Abstractions%20-%20Logic,%20Language,%20and%20Analysis.txt) The limitations of [specifications written in natural language](https://wiki.g15e.com/en/pages/Specification%20written%20in%20natural%20language.txt) ## Case 2. Design `width: 1024px` vs. `max-inline-size: 60rem` Placing elements on a canvas vs. declaring intent [Declarative design and the design runtime](https://wiki.g15e.com/en/pages/Declarative%20design%20and%20design%20runtime.txt) ## Attempt 1. Code quality management [Source code quality in the age of AI](https://wiki.g15e.com/en/pages/Source%20code%20quality%20in%20the%20AI%20era.txt) 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](https://wiki.g15e.com/en/pages/Agentic%20coding%20experiment%201.txt) 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](https://wiki.g15e.com/en/pages/Software%20engineering%20in%20AI%20era.txt) ## Attempt 3. Upfront design, traceability April-July 2025 [Semi-structured software spec](https://wiki.g15e.com/pages/Semi-structured%20software%20spec.txt) - A structured specification based on files - s4 CLI: a CLI tool that manages context and provides instructions based on that specification Current status + impressions - [Beneficially relating elements](https://wiki.g15e.com/pages/Beneficially%20relating%20elements.txt): beneficially connecting humans + code + LLMs - [Stateless AI-human interaction](https://wiki.g15e.com/en/pages/Stateless%20AI-Human%20Interaction.txt) 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