The licence for an AI coding assistant is a small line in the budget. The review time it creates is not, and that cost lands on your most senior developers. Generated tests, low-code platforms and domain-driven design work the same way: each helps with something specific and each moves a decision somewhere else instead of removing it. Adopt one without naming where that decision now sits, and you find out during code review, or in production on a Friday evening.
This piece takes the four practices one at a time. For each, what it is in plain terms, what it is good for, what it costs that the pitch leaves out, and who should sign off on its use.
AI Coding Assistants Still Need a Reader
Assistants such as GitHub Copilot sit inside the code editor and suggest code, boilerplate and explanations of unfamiliar libraries. They save trips to the documentation and speed up the repetitive parts of the day, such as the fourth near-identical API endpoint or yet another date-parsing helper.
Somebody still has to understand that code, because somebody will own it at two in the morning. A suggestion can compile, pass a quick glance, and still pull in the wrong library version, skip an edge case, or swallow errors in a way the rest of the system does not expect. The faster code arrives, the more of it the reviewer has to read, so the saving at the keyboard can come back as a queue at review.
The other question teams ask too late is what leaves the building. When a developer asks for a suggestion, some of the surrounding code goes to the tool's provider. Does the client contract allow that, and who agreed to it? We ask before the assistant is switched on for a client repository, and we get the answer in writing.
- 01Promptin the editor
- 02Suggestion
- 03Developer reads itcan they explain it?
- 04Testswritten or checked by a person
- 05Code reviewsame bar as any change
The review step does not get shorter because the code arrived faster.
Generated Tests Are a First Draft
AI tools can draft unit and integration tests and point at code that looks risky. That takes care of the dull part. The hard part was never typing the test. It was deciding what the code should do, and a test generated from the current code tends to confirm the current behaviour, bugs included. If the GST rounding function rounds the wrong way, the generated test will assert that it rounds the wrong way, and it will pass.
So we treat generated tests as a starting draft. Tools that predict fragile areas or flag unusual behaviour can help decide where people look first, but they produce suspects, not verdicts. A person checks that each assertion states a requirement rather than a snapshot of whatever the code happened to return on the day.
Low-Code Fits the Edges of a Business
Low-code platforms let people build small applications through visual editors with little or no programming. They are useful for internal tools, simple workflows and prototypes, where a business team can build something without waiting in the development queue. A leave-approval flow, a visitor register, a form that drops a lead into the CRM. They fit best when the logic is simple and the data lives somewhere else.
Trouble starts when one of these grows into something other systems depend on. Take a coaching institute whose operations team builds a fee-reminder app on a low-code platform. Within a year the admissions counsellors, the accounts team and the WhatsApp reminders all run off it. Version control, testing, access rules and upgrades are now hard to apply, and moving off the platform means a rebuild nobody budgeted for. Decide up front who owns each low-code app, and what happens on the day it becomes critical.
Domain-Driven Design Starts with Business Nouns
Domain-driven design, often shortened to DDD, organises software around business concepts and a vocabulary that developers and business experts share. The aim is that each module in the code matches something the business would name without prompting. It has no licence fee. What it costs is time with the people who know the business, and that is usually the hardest budget to get.
Profit Lever Models, a driver-based finance platform BizHues built, organises its model library by finance concept: revenue (new, expansion, churn), COGS, headcount, OPEX, capex and working capital. A connected three-statement engine ties them to the P&L, cash flow and balance sheet. Finance staff can reason about a hiring change or a payment-term change by finding the module it belongs to. That is the kind of boundary this approach looks for, though it is a finance-modelling example and not an AI one. The Profit Lever Models project story covers the rest of the platform.
- Revenue
- COGS
- Headcount
- OPEX
- Capex
- Working capital
Each module maps to a concept finance teams already use.
Boundaries like these also decide how well a system grows. Our piece on designing software architecture that can grow goes further into where module lines should fall.
Mistakes That Cost the Most
The same pattern shows up across all four. With assistants, developers accept suggestions faster than anyone can review them, so the reviewer becomes the bottleneck and the review gets shallower to keep up. With generated tests, the team trusts a suite that mirrors the code instead of the requirement, and gets a green build that proves nothing. Low-code apps spread with no owner and no backups, until one of them stops working and nobody knows which Google Sheet it was reading from.
On the design side, modules get named after technical layers instead of business concepts, so one change to how discounts work touches every module in the system. Teams also roll a practice out across the whole organisation when it suits only part of the work. And the data question gets left out entirely. Nobody can say what goes to outside tools, or who approved it.
In my view, every one of these is a decision that was never assigned to anyone. The tools did what they were sold to do. Nobody was named to decide how far to trust them.
A Decision Rule for Each Tool
| Practice | Allowed when | Who signs off |
|---|---|---|
| AI assistant | The developer could have written the code and can explain it | Tech lead, after the data question is answered |
| Generated tests | Each assertion matches a written requirement | The reviewer of the change |
| Low-code app | Internal workflow with a named owner and an exit plan | Business owner and IT together |
| Domain modules | Each module maps to a noun the business uses | Product owner and architect |
Start with the last row. It needs a whiteboard and two hours with the people who run the business, and it costs nothing in licences. List the nouns they use without prompting, circle the ones that deserve their own module, and put a date on reviewing the result. Once the team agrees on the nouns, the other three rows become much easier to judge. For how the same questions of ownership play out on web platforms, see what AI and automation change in web development.
