Prove You’re Better Than a Mac Mini
TL;DR: Be proactive and master the art of harnessing coding agents.
I sometimes ask my mentee a question during mock interviews: “Prove to me that you’re better than a Mac Mini.”
It sounds harsh, maybe even politically incorrect. But as a startup CTO, I think it’s becoming a very real question. Some of our mentees have gone on to land jobs at places like JPMorgan, engineer in hudge fund, and promising startups, and I genuinely believe the expectations for junior engineers are changing faster than most people realise.
Let me explain why.
My coding setup: 3 machines, 7 coding agents
Right now, I have three Apple machines running coding agents, each with its own responsibilities:
- Mac Mini M4, 16GB: Two Claude Code instances focused on feature implementation and infrastructure improvements.
- Mac Mini, 16GB: Two Claude Code instances handling technical debt cleanup and reliability improvements.
- MacBook Pro M4 Pro, 48GB: Claude Code instances working on features and hotfixes, alongside Codex for automated QA against our development environment.
These agents work in parallel, handling everything from implementing features to maintaining code quality and running tests. The goal is to keep development moving around the clock, even when I’m not sitting in front of a computer.
I manage the sessions through T3 Code. It’s in alpha, still some bugs, but it allows me to check progress, review what agents are doing, and provide instructions from my phone. I can do this on the train, between meetings, or even while having dinner with friends. That’s probably not the healthiest work-life balance, but it’s the reality of building an early-stage startup. As a CTO, work tends to follow you everywhere.
Now think about the economics. A Mac Mini costs a few hundred pounds. Add a Claude Max subscription, configure the environment properly, and suddenly you have a coding agent that can implement features, write tests, fix bugs and work through technical debt. It doesn’t get tired, doesn’t complain about repetitive tasks, and can keep working as long as the environment and task allow it.
This leads to an uncomfortable question: if your primary value as a software engineer is taking a well-defined ticket and turning it into code, what makes you more valuable than that Mac Mini?
I don’t think the answer is writing better code or typing faster. Increasingly, I think it comes down to two skills.
1. Be proactive: see problems before someone assigns them
Coding agents are already remarkably good at implementation, especially when given precise instructions and sufficient context. What they still struggle with is understanding the bigger picture of a product and independently recognising what should be improved next.
For example, I might be looking at our operational dashboard and suddenly think: We’re missing a chart that shows the end-to-end journey of a message. That would make debugging much easier. Or while working with our Telegram integration, I might realise that adding a search tool would give agents much better context from previous conversations.
Another day, I might get frustrated that changing LLM models for different clients requires too many configuration changes. That frustration becomes an idea: Why don’t we introduce model aliases so we can switch the underlying model without touching every client configuration?
These aren’t tasks someone assigned to me. They come from using the product, understanding the architecture, noticing friction and asking whether something could work better.
Of course, you can ask a coding agent to review a system and suggest improvements. Sometimes it will come up with genuinely useful ideas. But someone still needs to understand the business, recognise which problems matter, connect different parts of the product and decide what deserves attention.
That’s what I mean by being proactive. Don’t wait for someone to create a Jira ticket. Explore the product, question existing decisions, identify bottlenecks and propose improvements. The most valuable engineer isn’t necessarily the person who finishes the most tickets, but the one who discovers what the team should be working on.
2. Learn to harness coding agents, not compete with them
Here’s another question I would ask during an interview: “If I give you two or three Mac Minis and expect five good PRs every day, how would you make that happen?”
Get Craig Li, Ph.D’s stories in your inbox
Join Medium for free to get updates from this writer.
The answer isn’t simply opening five Claude Code sessions and giving each one a task. Anyone can do that. The challenge is building an environment where multiple agents can work productively without constantly stepping on each other’s toes.
You need to think about how tasks are decomposed, how to isolate coding environments with separate worktrees or repositories, and how to provide each agent with the right context. You also need automated validation: linting, unit tests, integration tests, end-to-end tests and perhaps another agent reviewing the code before a human looks at it.
And what happens when things go wrong? What if two agents modify the same interface? What if one introduces a change that breaks another feature? What if the tests pass, but the implementation fundamentally misunderstands the product requirements?
This is where engineering experience and system design become important. You’re no longer just writing code; you’re designing a development process that allows machines to write code reliably.
I think of this as harness engineering. The coding agent is the engine, but the harness determines how effectively that engine can operate. A powerful model with poor context, unclear instructions and unreliable testing can create more problems than it solves. A well-designed harness, on the other hand, can turn a few relatively inexpensive machines into a surprisingly productive engineering setup.
Five PRs a day sounds impressive, but five poorly designed PRs just create technical debt faster. The objective isn’t to maximise the amount of code generated. It’s to maximise the amount of useful, reliable software delivered.
AI hasn’t changed software engineering. It has accelerated it.
Despite all the excitement around coding agents, I don’t think AI has fundamentally changed the principles of software engineering. Good architecture still matters. So do testing, reliability, maintainability, security and understanding what customers actually need.
What has changed dramatically is the speed at which we can explore ideas, implement solutions and get feedback.
Previously, you might spend several weeks implementing an architectural approach before discovering its limitations. Today, you can discuss multiple approaches with an agent, ask it to compare their trade-offs, prototype different implementations and evaluate the results in a fraction of the time.
But there’s an important consequence that I think we aren’t discussing enough.
Traditionally, junior engineers develop into senior engineers through experience. They write code, encounter problems, make mistakes, debug complex systems and gradually build an intuition for architecture and engineering trade-offs. That experience is what eventually allows them to make good technical decisions.
Now, coding agents can handle much of the implementation work that used to provide those learning opportunities. If junior engineers simply accept whatever the agent produces, they might become extremely productive without developing the understanding needed to become senior engineers.
Being able to generate code is not the same as understanding software engineering.
I think the solution is to become much more deliberate about learning. When an agent suggests an architecture, ask why. Ask it to propose alternatives, challenge its own design and explain what might fail as the system scales. Discuss the trade-offs, experiment with different approaches and compare the results.
Most importantly, make the final judgment yourself and understand the reasoning behind it. Every interaction with an agent should be an opportunity to develop your own engineering knowledge, rather than simply outsourcing another decision.
AI can make you faster, but it doesn’t automatically make you better.
So, can you prove you’re better than a Mac Mini?
I don’t believe junior software engineers are becoming irrelevant. In fact, I think this is an incredibly exciting time to enter the industry. You have access to tools that allow you to build, experiment and learn at a pace that would have been unimaginable a few years ago.
But the bar is changing. Writing code is becoming less of a differentiator, while recognising valuable problems, understanding systems, making sound decisions and orchestrating AI agents are becoming increasingly important.
If I were interviewing a junior engineer today, I wouldn’t be particularly interested in whether they could write Python faster than Claude Code. I’d want to know whether they could take an ambiguous product problem, turn it into a clear technical plan, coordinate a few coding agents to implement it, and take responsibility for the quality of the result.
Even better, I’d want them to come back with an improvement I hadn’t thought of.
So when I ask, “Prove you’re better than a Mac Mini,” I’m not asking you to compete against a machine at writing code. I’m asking whether you can bring the curiosity, initiative and judgment that make those machines genuinely useful.
Because the future of software engineering isn’t about how much code you can write yourself. It’s about how much you can accomplish, how well you understand what you’re building, and how effectively you can turn your ideas into reliable software.
Don’t compete with the Mac Mini. Learn to master it.
