Monday morning, first week of your year out. Someone forwards you a DWG from the structural engineer with the message: "can you overlay this on the GA and mark up where the grid doesn't line up — by four?" There are eleven xrefs, a layer list in someone else's naming convention, and three layouts with viewports at scales you didn't set. Nobody is going to explain any of it to you. They assume you can read it, because reading it is the baseline.
That is the honest answer to the AutoCAD-or-Rhino question. Learn enough AutoCAD to open, read, edit and issue a drawing set before you graduate. Keep Rhino for the work that is yours. They are not competing for the same slot in your brain, and treating them as rivals is why so many students end up mediocre at both.
AutoCAD is not a design tool and hasn't been for years. It is a documentation language — a shared set of conventions about layers, line weights, scales, annotation, sheets and references that the entire construction industry can read regardless of what software drew it. The .dwg file is the lingua franca. Consultants send them, contractors mark them up, surveyors issue topographical surveys in them, local authorities receive them. The software is incidental; the literacy is the point.
Rhino is a workshop. It is where you make the form, test it, break it, push a surface somewhere it shouldn't go and find out whether it still works. It has no opinion about how buildings are drawn because it has no opinion about buildings. It will happily model a kettle, a stadium or a pair of trainers. That neutrality is exactly why it is brilliant for design work and exactly why nobody is going to issue a planning set out of it.
So the question isn't which one is better. It's which one you are being asked for, and when.
What AutoCAD Is Genuinely Bad At
Let's be fair to Rhino before anyone accuses me of nostalgia.
AutoCAD is bad at form. Anything that isn't orthogonal, extruded or made of arcs becomes a grind. It has 3D tools; they exist the way a fire exit exists — technically available, unpleasant to use, and you hope you never need them. Modelling a double-curved roof in AutoCAD is a form of self-harm.
It is bad at iteration. The geometry is dumb. Move a wall and nothing else knows. There is no history, no parametric relationship between the thing you drew and the thing you drew next, so changing your mind costs you the same effort as drawing it the first time. Rhino with Grasshopper will regenerate forty variants while you make a coffee.
And it is bad at thinking. Drafting is a recording medium. You use it when you already know what the thing is. If you are still finding out, AutoCAD will punish you for every exploratory move.
What Rhino Is Genuinely Bad At
Rhino has layouts, annotation styles, dimensions and Make2D. On paper it can document a building. In practice, here is where it falls apart.
Make2D output needs cleaning. Every time. On a heavy model it is slow, and the linework it spits out arrives as a lump you then have to sort into layers and weights by hand — which is drafting, just done badly and after the fact. You've done the work twice.
There is no shared convention. Rhino doesn't care what your layers are called, so nobody's Rhino file looks like anybody else's. AutoCAD's rigidity is an irritation when you're alone and a gift when eight consultants are working on the same building.
And there is no issue culture. Revisions, drawing numbers, title blocks, transmittals, a sheet set that someone can check against a schedule — Rhino has no real answer for any of it, because that was never what McNeel built it for. The moment a drawing has to leave the office with your practice's name on it and a date and a revision letter, Rhino hands the job to something else.
If you want the detail on how modelling work gets handed over to a documentation platform properly, we've written about the Rhino-to-Revit workflow separately. The short version: the handover is a real piece of work, and knowing drafting conventions is what makes you good at it.
What You're Marked On Now vs What Lands on Your Desk in Week One
Studio marks ideas and representation. Nobody has ever failed a crit because their layer names were a mess. Your tutors want to see a position, a form, a drawing that argues something — and Rhino, with a decent render engine behind it, is a very efficient route to all three. That's why the studio floor is full of it.
Practice marks something else entirely: can this drawing be built from, coordinated against other people's drawings, and issued without embarrassing anyone. That's a different skill with a different vocabulary, and nobody teaches it in school because it isn't what school is for.
So you arrive with a portfolio full of beautiful Rhino work and get handed a DWG. In my experience that first week is where year-out students either look capable or look lost, and it has almost nothing to do with how good their design work is.
The Hiring Question, Answered Honestly
I'm not going to give you a percentage of UK job adverts mentioning one tool over the other, because I don't have a dataset I'd stand behind and neither does anyone else writing these articles — the confident-sounding numbers you'll read elsewhere are invented.
What we've found, from hiring and from watching students go through year-out placements, breaks down like this.
Your portfolio gets you the interview. The software list on your CV is a filter, not a differentiator — it gets you past the first sift and then nobody mentions it again. No practice has ever hired a Part 1 because they listed six packages. They hire because the work looked like it was made by someone with judgement.
The software question that actually gets asked in the room is narrower than you think: can you pick up an existing set and work in it without someone holding your hand. That is a drafting-literacy question, not a modelling question. Being able to open a file, find your way around the layers, set a viewport scale, plot to PDF at the right size and not detonate someone else's xrefs is a low bar that a surprising number of graduates fail.
And there's a UK-specific wrinkle. The year out between Part 1 and Part 2 is typically a support role — you are producing and coordinating drawings, not leading concept design. That is the stage where documentation fluency pays and form-finding doesn't, which is the inverse of what your degree just trained you for. By Part 2 and after Part 3, the balance tips back: the design-led roles want the modelling, the computational work, the ability to drive a competition entry. The sequencing is the whole point. You need documentation skill first because that's the stage you hit first.
The Bit Nobody Sells You: Drafting Is a Learnable Set of Conventions
Here's the good news. AutoCAD is small. The command set you need in practice is genuinely modest — draw, modify, layers, blocks, hatches, dimensions, xrefs, layouts, plot — and most of it is muscle memory you build by making a real drawing rather than watching a tool-by-tool tour.
That's exactly how we structure our own AutoCAD course: the first lessons cover the interface and the draw and modify tools, then you spend the bulk of it tracing and reconstructing Fallingwater — plans, elevations, sections, hatching, entourage, annotation, then layouts and plotting at the end. Attaching Wright's drawings as external references and drafting over them is not a cute exercise; attaching, scaling and working over someone else's file is precisely the task you'll be handed in week one, whether it's a topo survey, a consultant's DWG or a client's title plan.
How Long Each One Actually Takes
As a rule of thumb, from what we see students manage: you can get to useful, employable AutoCAD in a few focused weeks of evenings — because the goal is competence in a closed set of conventions, not mastery. There is a ceiling, and it's low, and that's a feature.
Rhino has no ceiling. You can be making simple massing in a weekend and still be learning surfacing and Grasshopper five years later. Treat it as a long, slow accumulation alongside your studio work rather than something you "complete".
Which tells you how to spend a limited term: short sprint on the drafting, continuous drip on the modelling.
Does One Make the Other Easier? Yes — In One Direction
Learn AutoCAD first and Rhino gets cheaper to learn, not the other way round.
Rhino inherited the command-line workflow wholesale. Type the command, read the options in the prompt, pick a base point, enter a value. If you already type M, space, click, click in AutoCAD, you already work the way Rhino wants you to work. Layers, snaps, precise coordinate entry, the habit of drawing to real dimensions rather than eyeballing it — all of it transfers straight across.
It transfers to Revit too. Revit's sheets-and-viewports logic is AutoCAD's paper space with the training wheels bolted on, and a student who understands why a drawing is laid out at 1:50 on an A1 sheet picks up BIM documentation far quicker than one who only knows how to model.
Go the other way and you learn none of it. Rhino never forces precision on you, so you can get quite far making things that look right and measure wrong.
What You Can Actually Get Hold Of
One practical note, because it changes the maths for a lot of students: Autodesk runs an education programme giving students and educators free access to its software for personal learning, so AutoCAD at home costs you nothing but a verification form. McNeel sells Rhino outright, with a cheaper educational licence and a time-limited free evaluation of the full version from their own download page.
The upshot — AutoCAD is the one you can practise with for free, indefinitely, through university. There's no excuse.
The Sequence
Learn AutoCAD now, properly, to the point where you can take a reference file, draft a clean set of plans, sections and elevations over it, annotate them, lay them out and plot them. Treat that as literacy rather than a skill — it's the floor, not the ceiling.
Run Rhino alongside it for your own design work, forever, and let it grow at whatever rate studio demands.
Then, when you've got both, understand what you're actually being judged on. Nobody gets hired for a software list. They get hired because the work is good and because they won't need babysitting when a DWG lands in their inbox on a Monday morning. One of those takes three years. The other takes a month.
