By Pavan Kumar T V ·
The Designer Who Never Dreamt He Could Build It Himself
Pranav is a designer at Archana Automotives. For years his job was Photoshop.
A customer walks in wanting a luxury conversion on a Force Urbania. They describe roughly what they have in mind. Pranav disappears, builds a layout by hand, brings it back. The customer looks at it and changes their mind. Pranav goes away and builds another one.
He was visualising, one option at a time, at the speed of a mouse. And he was never in the room for the conversation. The owner did all the talking.
Today Pranav manages and releases a vehicle configurator. Wheelbase, layout, mix the interior units, and the thing checks every arrangement for whether a human being can actually walk through it before it draws anything. He owns it.
That took five one-hour sessions across four weeks.
I want to be precise about that sentence, because "AI turns anyone into a developer" is the laziest claim going around right now, and it is not what happened here.
What the five hours were spent on
Not syntax. Not JavaScript. Not React. He has still never sat down to learn a language.
How to work with the AI. Most of it. This is the part nobody teaches and the part that decides everything.
A model of the world. What a repository is. What a branch is. What "the server" means as opposed to "the browser." Not so he could build any of it, but so that when the machine tells him something he can tell whether it makes sense in the place he is standing.
Small HTML layouts before anything real. Make a box. Make it red. Put another box beside it. Break it deliberately. A designer already understands why you sketch before you paint, so this needed no selling.
Then GitHub, Vercel, deploys. How his work travels from his machine to a link a customer can open. Most teach-yourself material leaves this to the final chapter. It should be the second one, because something that isn't deployed isn't real, and he needed to feel that loop close early.
Five hours, spread over four weeks rather than crammed into a weekend. The gaps are where the learning actually happened. He hit real friction alone and brought it back.
The moment it turned
For the first stretch, Pranav fought the AI.
He would ask for an interface. It would give him something not quite right. He would tell it that it was wrong. It would apologise, and hand him something else not quite right. He would explain again, more emphatically. Round and round, getting angrier at a machine.
He was pleading with it. Trying to make it want what he wanted.
The shift was to something completely different: work out what you need, then ask for exactly that. Not "make this look better." Not "no, not like that." Instead — what is the actual arrangement, what are the constraints, what happens when this is too wide, what is the rule underneath the taste.
That is not a prompting trick. It is what a designer already does when briefing a junior, and what a decent engineer does when writing a ticket that doesn't bounce back with questions. The model simply makes the cost of being vague immediate and visible.
The skill isn't prompting. It's specifying. Somebody who cannot describe what they want in a form another person could act on will not get there by describing it to a machine instead. And somebody who can describe it — a designer, an ops lead, anyone with twenty years of pattern recognition in a domain — is far closer to shipping than they believe.
Teaching that took most of my five hours, and none of it was technical.
Where the line sits now
Pranav runs the business logic. Which units can coexist. Which combinations are excluded. What looks wrong to a customer even when it fits perfectly well geometrically. Which layout is the one worth putting in front of somebody first.
That is the valuable half, and it is the half I could not do. I have never sold a vehicle conversion in my life. He has watched hundreds of customers react to layouts and knows what makes a face fall.
What comes back to me is architecture. When the thing needs restructuring rather than changing, that is mine. He knows where that boundary sits, which is itself a learned skill and took longer than the deploys did.
It is not senior and junior. It is domain owner and structure owner, which is a much healthier arrangement than most engineering teams manage.
What it changed for the business
The owner got his time back. He no longer has to stand in every meeting narrating options, because the options are on a screen and the customer can drive them.
It changed how the company reads to a customer, too. A body builder who hands you a configurator is a different sort of company from one that hands you a printout. That was never in the brief and might be worth more than the tool.
And it moved the ambition. The target now is an Airbus-style configurator — the customer builds the entire specification themselves and the constraints hold their hand the whole way. Nobody was thinking that in week one. It only became thinkable once the first crude version was real.
The thing worth taking
I keep coming back to this one, because it is where the shift in our industry actually shows.
For twenty-five years the arrangement was fixed: the person who knows why the layout is wrong tells the person who can change it, and something is lost in the handover every single time. We built entire professions around that translation layer — specs, tickets, standups, three-week cycles to move an idea across a desk.
Pranav skipped the translation. He knows why it's wrong and he now changes it himself.
I did not teach him a craft. I taught him to brief, gave him tools that respond to a good brief, and got out of the way. Five hours, and the man who spent years waiting on somebody else to build his ideas now releases the product his company sells with.
That is a much shorter path than teaching me the vehicle business.