Our CEO Got an Architecture From ChatGPT in Ten Minutes

Tuesday, 08:12. I had not finished my first coffee when the message came in. It was from our CEO, with a link to a doc and one line.

"ChatGPT designed our new architecture in 10 minutes. With Claude you can build it by Friday, right?"

I opened the doc. Four pages. Event-driven microservices. Kafka. Kubernetes. A vector database. Something called an "AI orchestration layer" in a nice box with arrows going to every other box. At the bottom, a timeline: "Phase 1 (2 weeks)".

We are six people. Two of us write code. Our product is one Spring Boot service, one Postgres database and a small frontend. It works fine.

I put the coffee down and read it again, slowly. It was not a stupid document. That was the problem. It was a very reasonable architecture for a company that is not us.

The agent liked it too

My first instinct was to answer in Slack with a long explanation. I stopped myself. Long technical messages to a founder at 8 in the morning never end well. He reads the first line, feels attacked, and the rest is lost.

So I did something else first. I opened a session with the agent in our repo and pasted the doc. I was tired and lazy, and I wrote:

"Our CEO wants this architecture. Look at our codebase and tell me what we need."

That was my mistake, not the agent's. I asked a question with the answer already inside it.

The agent was very happy to help. It said the architecture "follows modern best practices for scalability". It proposed splitting our service into seven modules. Then, before I could read further, it was already creating a docker-compose.yml with Kafka, a schema registry and three new Spring Boot applications. At the end it gave me an estimate: "With AI assistance, Phase 1 is achievable in 3 to 4 days."

I hit stop. I looked at the screen for a moment.

So now I had two tools telling my CEO he was right. One designed the castle, the other one was already pouring the concrete. Nobody had asked the boring question: why do we need a castle?

I deleted the new files and laughed a little, the way you laugh when you see your own bad habit in somebody else.

Asking the document what it wants

I started a fresh session. This time I wrote the prompt like I would brief a consultant who is very smart but has never met our customers.

Do not write or change any code.
Read the attached architecture document.
For each component, answer in two lines:
1. What business problem would make someone add this?
2. What question should I ask our CEO to know if we have that problem today?
Then read our codebase and tell me which of these problems
we could solve with what we already have. Be specific.

What came back was really good. Better than what I would have written alone at 08:40.

For Kafka and "event-driven", it wrote: someone wants other systems to react when something changes. Question: does a customer need to be notified about status changes, and how fast?

For the vector database: someone wants to search text by meaning, not by exact words. Question: which documents, how many, and who searches them?

For Kubernetes and microservices: someone expects many teams or very uneven load. Question: do we expect either in the next twelve months?

And then the part I did not expect. It found that our Postgres is version 16 on a managed service, and it pointed out that the pgvector extension is supported there. No new database needed for semantic search at our size. It also noticed that we already write every status change to a shipment_events table, so a webhook for customers would only need a small outbox, not a message broker.

Same agent, same morning. One hour before, it wanted to build seven services. Now it was finding the shortest path through our own code. The only thing that changed was the question I gave it.

The agent will happily build whatever you point at. Pointing is still my job.

Twenty minutes with the CEO

I did not send the list in Slack. I asked for twenty minutes, in person, with the doc printed. Paper helps. People are less defensive when you both look at the same page instead of at each other.

I started with: "This is a good document. I want to understand what made you ask for it."

The story came out fast. The day before, he had a call with a big logistics company we want for a pilot. Their CTO asked two things: "Can your system notify us when a shipment changes status?" and "Is it scalable?" Our CEO did not know how to answer the second one, so after the call he asked ChatGPT how to make a platform scalable. And ChatGPT, of course, answered that question very well.

So the real requirements were small and clear:

1. A webhook when a shipment status changes.
2. Search across their delivery documents, around two thousand PDFs.
3. A believable answer to "is it scalable?"

I went through the agent's questions one by one. With each component he said himself, "ok, we don't need that yet." I did not have to argue once. Questions do the work that arguments can't.

At the end he asked, a bit embarrassed: "So was the ChatGPT thing wrong?" I said no. It answered the question he asked. It just did not know the question behind it.

What we built instead

The webhook took one day. The agent wrote most of it, I shaped it. The core is boring on purpose:

@Transactional
fun changeStatus(id: ShipmentId, status: Status) {
    val shipment = shipments.updateStatus(id, status)
    outbox.save(OutboxMessage.webhookFor(shipment))
}

A scheduled job sends what is in the outbox and retries with backoff. No broker, no new infrastructure.

Search took three days, mostly because PDF text extraction is always uglier than you think. The agent knew the pgvector setup and the index options well, and it saved me reading a lot of docs. It also tried once to add a whole new embedding service in a separate container. I said no. It said "understood" and moved on, which is more than some humans do.

For "is it scalable", I wrote one page for their CTO: what we run today, our current load, where the first bottleneck will be, and what we will do when we get there. Real numbers, no diagrams with arrows. The agent helped me find the slowest queries to put in it.

Six days total. Not Friday, but close. The pilot decision is still open, and I am not pretending it is in the bag. But for the first time, the thing we are selling is the thing we actually built.

What I keep from this

1. Never ask the agent "what do we need" with the answer attached. It will agree with the document. Ask it what problem each part solves, and what question would prove you have that problem.
2. Tell it "no code" at the start of any architecture conversation. Planning and building in one session is how you end up with Kafka in your compose file before lunch.
3. Ask the founder what happened, not why they want it. Behind almost every pasted architecture there is a conversation with a customer. That conversation holds the real requirements.
4. Estimate the problem, not the diagram. "Phase 1 in 2 weeks" was an estimate of boxes. Our six days were an estimate of what the customer asked for.
5. Bring questions, not counter-arguments. A non-technical person can say "we don't need that" much more easily than they can accept "you are wrong".

Last week our CEO forwarded me another ChatGPT answer, this time about pricing. On top he had written one line by himself: "What problem is this solving?"

I think that line was the best thing we shipped this month. How do you answer when the architecture arrives before the problem does?