What are your goals for your software development?
Maybe you have a new software product idea and you are starting fresh. Maybe you need features added to an existing system. Is that system simple or complex, and maybe you don’t know the difference? Maybe your existing system needs porting, or updating. Maybe your system is buggy. Maybe it isn’t designed for automatic scaling or recovery. So, first things first, know what you need.
Design by Use (DBU) is a simple mantra and principles to guide you. DBU encompasses Test First Development, Domain Driven Development, and any process where a usage example could be used to initiate the design process.
And this brings us to our topic.
How should your software company be using AI? That is so important for you to know because if you do not know you can be subject to influences that are trying to sell their AI solutions. When we go grocery shopping we usually have a list. When we don’t have a list we are more easily influenced by advertising. Have you ever returned home and unpacked and thought “I don’t need this, what was I thinking?”
You must design your AI infrastructure and your AI usage around concrete needs and expectations. Consider the mantra of Design By Use and let it help you.
When I design a database and use DBU the first thing for me is to define as many queries as possible. The more legitimate queries I can capture the more the structure of the database will emerge. If I go too quickly to the data structure I want returned I find the schema does not define relations to service efficient queries and instead just services simple data transfer objects.
I recently read “The Five Levels: from Spicy Autocomplete to the Dark Factory” by Dan Shapiro. Do those levels define the levels that your company needs to strive for? If the fifth level is achievable does it make a company that you want to work at? If it does then great. If it does not, what is important to you and your company? If you are a software engineer does the five levels define a career path that interests you? It is important for you to know and for you to make informed career choices.
I believe the idea of the dark factory is achievable. I think some advances that are yet to come will make it possible. Just one thought of many for dark factories, there is no need for AI to generate high level language code for a dark factory because languages like C to Swift are made for humans, not for the machine. AI could generate a special language, byte code, assembly, or even machine code. Models will have to train, maybe in a bootstrap fashion, to get from specification to AI code, whatever that AI code is.
I see other possiblities with AI.
I propose three People Levels and three Platform Levels.
People Levels
People Level 1 — Force Multiplier
Not every company may want to be a dark factory. I see opportunities for workplaces where people see AI as a force multiplier. I see a bright future. I see the ability for a software engineer to express their ideas more robustly and founded on better software engineering principles. For example one of the software engineering principles that is commonly viewed as good design is the Whole Value.
The “Whole Value” is using a structure of some type to represent the data instead of relying on the built in type. If you have code that takes a parameter for a person’s given name you might have:
void myMethod(String givenName)I have done that so often because I rationalized that writing a class called GivenName was overkill. I currently work in Java 21 and it has a datatype called “record” that makes it memory efficient to make whole value types. With AI I have it generate my whole value and include validation code so that it is easy to know if “123-Billy-Bob” is a valid given name or not. I also have AI write full coverage tests on these whole values with more variations of inputs than I would normally type in myself as well as full serialization and deserialization tests.
Now what was tedious is now trivial and the known benefits of whole values are easy enough that I use them and gain their benefits. Have you ever wanted to do the Null Object pattern but feel there is just no way to introduce it? A Null Object is an object with no behavior and the pattern allows you to clean up error and exception handling code. Maybe with AI as a force multiplier you could finally implement that pattern if you find the need and justification for it. You should read about Ward Cunningham’s CHECKS Pattern Language of Information Integrity (1994).
Another example of using AI to help with my preferred coding practices is that I prefer methods that have single exit points. If I struggle figuring out the conditions of return I can write the routine with multiple returns, have AI write robust unit tests for every return path, then have AI assist me in converting the method to a single return pattern. If all tests pass then I have a level of confidence that the conversion was correct. AI can assist you with any coding pattern you find valuable and appropriate for the current domain and context.
People Level 2 — Trust the Team
Now that we have introduced AI as a force multiplier it is important to allow the people and teams to define how they will use AI. It is tempting to create company AI directives. The allure of forced standardization is powerful. My experience has shown that good practices are generally known. Accepting that teams are more aware of bottlenecks and friction points and encouraging them to make their job and output better can result in micro-improvements that add up to noticeable macro outcomes.
From Maverick: The success story behind the world’s most unusual workplace by Ricardo Semler (Warner Books, 1993), Chapter 11:
“The workers started changing their work, not just their work environment. They improved the way things were done, how the assembly of dishwashers was done, how inventory was maintained, the design of products, and the assembly materials. There was no approval needed to make a change, and the decisions made stayed. There were no special rewards for new ideas. It was a spontaneous process. People participated if they wanted to.”
Trust the team to use all of the tools in the way that addresses their needs. Trust does not imply no verification. There should be a review process that allows individuals and teams to get open feedback.
People Level 3 — Solution Builders
“Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot inflame or inspire the drudge.” — Frederick P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, Vol. 20, No. 4 (April 1987)
With Level 1 having AI tools that are used as force multipliers and Level 2 having those using AI to use it in the way that fits their situation, the environment exists for people to excel and provide a work product that can be seen and evaluated. For software engineers that would be running software that meets the requirements for runtime costs, response time (SLA), and any other requirement. This is where creativity and craft can be seen. AI is a tool for the creative and for those that have pride in their work.
There is an old parable that is enlightening.
Three stone cutters were asked about their jobs. The first said they were paid to cut stones. The second said they used special techniques to shape stones. The third stone cutter said: “I build cathedrals.”
Level 3 is the natural result of levels 1 and 2. Level 3 is Solution Builders.
Platform Levels
Now I would like to address some concerns using AI as a force multiplier.
How do specification details affect AI code generation? Has it been proven that the more detailed and complete the specification will result in a better AI generated system? It seems that the dark factory may mandate this.
From our People Level 2 we have to believe that the team knows best how things really work. If you are a product designer have you been more successful with big upfront design or iterative development? Are you willing to try and go back to designs that become immutable contracts? You need to think about such things. Is getting to a dark factory really the thing that you need? It may be, and then again, it may not be.
Platform Level 1 — Independent Regression Tests
For managers and product persons that are not engineers: do you understand repeatability? Currently the product requirements get converted into a programming language. That is the code and the code then becomes the product specification. Each and every time the engineers build the code the language tools generate the same result. Are AI code generators repeatable? If you feed the same specification prompt into AI will it generate the same result each and every time? When your AI model updates will it generate the same result as the previous? Because it is not repeatable there must be more adherence to regression tests. Regression tests are run against a system to ensure it doesn’t diverge from its previous behavior. These regression tests must be isolated from AI.
Regression tests are the application of the principle “Design by Use.”
Platform Level 2 — Company-Invested AI Specialization
For a software company that has an existing code base then ideally the AI tools would be trained on the best quality code the company has available. If your company has shared code libraries the system should be thoroughly trained on those libraries so that it will properly suggest their usage.
Platform Level 3 — The Enlightened Factory
Having AI tools that are trained on your company’s code bases and best practices becomes a force multiplier that allows prototyping, what I have called “scouting and recon,” and other forms of experimentation. As the people grow through the three People Levels and as the company progresses through the Platform Levels we can arrive at a system that feeds back and self-improves. As teams become more and more into cathedral builders and the company has a foundation of verification (regression tests) and specialized tools, the company can become an Enlightened Factory where ideas are generated into working prototypes — but not just working in an isolated way, but working by using the company’s existing assets and creating opportunities for adding new assets that will be used to train even better AI specializations and allow the people to show their ingenuity and creativity.
“The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.” — Frederick P. Brooks, Jr., “No Silver Bullet” (1987)
Conclusion
If your company’s goal is full software development automation then follow those promoting the dark factory.
If your company believes people are important — and I believe they are — then AI can lead to improvements that create software products built on known principles, multiplied through AI assistance. Equip your people. Trust your teams. Invest in your platform. The people will build cathedrals.
The Enlightened Factory is not a place where humans are neither needed nor welcome. It is a place where humans are essential, empowered, and proud of what they build.
