AI Writes the Code. You Still Do the Engineering

This is the clearest way I can describe my experience of building a real enterprise product almost entirely with AI.

The benefit in coding speed is undeniable. Going from an idea to a working prototype now happens at a speed that would have looked unrealistic even a year or two ago. Screens appear in minutes. APIs, database schemas, tests and deployment scripts can be created in hours. A single person can attempt something that previously needed a small team just to get started.

But a working prototype and an enterprise product are not the same thing.

Once the product has real users, real data, security requirements, operational dependencies and governance, the curve changes. AI still makes you faster, but the other parts of software engineering come back into the picture. Architecture, cybersecurity, code quality, testing, deployment, support and, most importantly, human judgment do not disappear because the code was generated quickly.

I learned this through a controlled experiment, although it did not start as an academic exercise. It started from necessity and urgency.

The experiment: build a real product with AI doing the coding

We needed an internal AI analytics and cost-chargeback platform, and we needed it quickly. This was not a demo application created to test a tool. It was an enterprise product that would eventually be used by thousands of people.

Given the urgency, I decided to approach it differently. The objective was not simply to find out whether AI could generate an application. We already know it can do that. The real question was whether one experienced engineer, using AI in a deliberate and controlled way, could take a product all the way from an urgent business need to enterprise use.

The control was in how the work was done. I made the product and architecture decisions. I reviewed the output. Security and quality checks remained mandatory. The AI could implement, explain and correct, but it did not get to decide what was acceptable for production.

The product was built in a matter of weeks. That result alone is significant. I do not think the same scope could have been delivered by one person at anything close to that speed using a traditional development approach.

So yes, AI coding delivers a very real advantage. But the more useful lessons came from looking at what happened after the first working version.

Coding speed is real, but coding is only part of delivery

The first versions came together extremely fast. AI was particularly effective when the requirement was clear and the change could be verified immediately. Creating an endpoint, adding a database migration, implementing a screen or generating tests could happen in a fraction of the normal time.

This creates a strange effect. Because code appears so quickly, it feels as if the product is nearly finished. In reality, you have reached the point where the engineering work becomes visible.

The question is no longer, "Can AI build this feature?" It usually can.

The questions become, "Should this feature work this way? Is the data exposure acceptable? Does this fit the architecture? Can another person maintain it? What happens when it fails?"

These are not coding questions. They are engineering questions, and the experiment showed that they remain firmly with the human.

Cybersecurity: a good starting point is not a security review

The security result was better than I initially expected. The AI-generated code used reasonably safe patterns. It did not produce obviously reckless implementations, and for a prototype the baseline would have been acceptable.

For an enterprise product, that was not enough.

Before real data was allowed to flow through the system, I had it reviewed properly. The review found one serious issue and several smaller ones: an endpoint exposed more information than it should, session handling needed to be stricter, and some data-changing routes needed stronger protection.

None of these were unusual vulnerabilities. That is exactly why they matter. Enterprise security failures are often not exotic. They come from ordinary decisions made without enough business and operational context.

AI can apply common security patterns, but it does not automatically know what a particular endpoint reveals about your employees, which data is sensitive in your organization, where encryption terminates in your infrastructure, or which action needs an audit trail. It can help implement a threat model. It cannot invent the correct threat model for your situation.

My observation is that AI gives you a useful security baseline for free. The mistake would be to confuse that baseline with a defensible production posture.

Code quality: AI responds well to gates

The application worked, but static analysis showed a predictable amount of quality debt. There was duplication, unnecessary complexity and inconsistency between implementations. AI would solve a problem in one place without always recognizing that the codebase had already established a different pattern somewhere else.

This is one of the practical differences between a fast contributor and an experienced maintainer. AI is very good at producing a solution. It is less reliable at protecting the coherence of the whole codebase unless that expectation is made explicit and continuously checked.

Better prompting helped, but it was not the final answer. Automated quality gates made the real difference.

Once static analysis, tests and review checks became mandatory, the results improved quickly. AI is very effective at correcting a specific issue reported by a tool. If the pipeline says there is duplication, a security hotspot or a failed test, it can usually understand the evidence and fix the problem quickly.

The lesson for me was simple: quality cannot live only in the prompt or in the memory of the model. It has to live in the engineering workflow. Standards should be written down, checks should be automated, and failures should block progress.

Architecture: AI tends to build more than you need

Architecture was the area where I had to provide the strongest direction.

AI has learned an enormous number of patterns, and it often reaches for the most complete one. That sounds useful, but completeness is not the same as suitability. Ask for a feature and you may receive an abstraction, a framework and a subsystem when a small implementation would have solved the actual problem.

At one stage, the AI created a full consent-management subsystem. It was internally consistent and technically plausible. It was also far beyond what the product needed. I removed it and replaced it with a simple terms flow.

This was not an isolated coding mistake. It was an architectural judgment call. Every unnecessary abstraction becomes something the product has to maintain, test, secure and explain for years.

I had to make the load-bearing decisions: what belonged in the system of record, what could remain disposable, where boundaries should sit, and what we would deliberately not build. Once those decisions were clear, AI implemented them well. But allowing it to make those decisions independently would have produced a larger and more complex system than necessary.

One thing I have learned over the years is that good architecture is not measured by how many patterns you can apply. It is often measured by how much unnecessary complexity you can refuse. AI is not naturally good at refusing.

Verification is limited by your own expertise

This was the most important and uncomfortable result of the experiment.

I am an architect and a backend developer. When AI generated backend logic, data models and system structure, I could review the code, recognize weak decisions and ask the right questions. AI increased my speed, but my experience remained the safety net.

Then I moved into front-end work, where I do not have the same depth of expertise.

The difference was immediately visible. I trusted the AI more, not because its output had become better, but because my ability to challenge it had become weaker. I could test whether the page worked, but I could not evaluate the component structure, design consistency, layering and user experience with the same confidence.

The product still carries signs of that gap. The interface does not have a strong and consistent standard. Dark mode has issues. Some flows may be technically correct without being genuinely good user experiences.

This is the risk behind the phrase "human in the loop." A human review is valuable only when the human has enough expertise to recognize what is wrong. Where you have strong knowledge, AI is an accelerator. Where you do not, it can quietly become a crutch.

So the quality you can deliver with AI is capped by the quality you can verify. The model is not the only limiting factor. Your own expertise, and your willingness to bring in people who cover your blind spots, matters just as much.

Why enterprise delivery becomes linear

For prototyping, the gain feels exponential because most of the old friction is in writing and connecting code. AI removes a large part of that friction. You can go from zero to something useful before a traditional team might have completed its initial setup and planning.

Enterprise delivery has a different shape. As the product becomes real, work that cannot be skipped starts to dominate:

• defining the right problem and scope;
• making architecture and data ownership decisions;
• reviewing security in the context of the organization;
• enforcing code quality and test coverage;
• validating user flows with the right expertise;
• preparing deployment, monitoring, support and governance;
• deciding what not to build.

AI can assist with every one of these activities. It can prepare documents, propose options, generate tests, respond to scan findings and automate repetitive work. But these activities need decisions, evidence and accountability. They do not compress at the same rate as code generation.

That is why I describe prototypes as exponential and enterprise products as linear. It does not mean the enterprise benefit is small. Delivering this product in weeks with one person would not have been possible otherwise. Linear improvement across a real delivery lifecycle is still a major competitive advantage.

It simply means that the impressive speed of the first prototype should not be used as the forecast for the whole product.

What I would recommend to engineering teams

Based on this experiment, I would recommend five things.

First, use AI aggressively for coding. The speed advantage is real, and avoiding it will not improve your engineering.

Second, keep the important decisions with people who understand the product and its consequences. Architecture, data sensitivity, risk and scope are contextual decisions.

Third, move standards out of prompts and into automated gates. Tests, static analysis, security scanning and architecture checks should produce evidence that both the human and AI can act on.

Fourth, be honest about expertise gaps. If nobody on the team can properly review a generated front end, infrastructure design or security model, the answer is not more confidence. The answer is to bring in someone who can verify it.

Finally, measure the complete delivery cycle, not only how quickly the first code was generated. The meaningful result is how quickly a secure, maintainable and supportable product reaches users.

In conclusion

This experiment started because there was a real need and very little time. It ended with an enterprise product in front of thousands of users, built in weeks with AI doing most of the coding. That is an undeniable result, and it changes what one engineer or a small team can attempt.

But it did not remove the need for software engineering. It made engineering judgment more visible.

AI wrote the code. I still had to decide what to build, what to remove, what to secure, what quality meant and which parts I was qualified to verify. Wherever those controls were strong, AI delivered remarkable leverage. Wherever my own expertise was weaker, the product showed it.

The bottleneck has moved from typing to decision-making. The teams that benefit most will not be the ones that simply generate the most code. They will be the ones that make sound decisions quickly, encode their standards into the workflow, and verify the output with the right expertise.

Prototypes are exponential. Enterprise products are linear. Both are faster with AI, but only one can be mistaken for being finished.