Read Part 1 here
The concerns about craftsmanship miss where craft actually operates. Handwriting every function was never craft. It was inefficiency performing as virtue. Real craft is knowing when to let AI generate boilerplate and when to architect manually, when that distinction matters and when it doesn't, how to create the constraints that keep AI productive, when to override what AI suggests because the context matters, and what the code needs to serve, not just what it needs to do.
Tailors still exist. They charge premium prices for bespoke suits. But they use sewing machines for what makes sense and hand-stitch what matters. They didn't refuse the machine because it threatened their craft. They understood that the machine let them focus their craft where it actually added value. The ones who refused sewing machines? They became hobbyists, not professionals.
The art of software engineering isn't syntax. It never was. The art is understanding what the system needs to do, how it needs to evolve, what tradeoffs matter, and what happens when it meets reality. That art doesn't disappear when AI handles syntax. It becomes the only thing that matters.
When code writing gets faster with AI, we can deliver the same value in fewer billable hours. We're experimenting with fixed pricing to capture that value in a different way. But here's what doesn't change: what clients actually pay for. When they hire a senior engineer, they're buying architectural decisions that prevent six-month rewrites, security oversight that AI can't provide, knowing when vibecoding is appropriate and when it creates debt, the ability to rescue systems without full rewrites, and understanding of business context that informs technical decisions.
That was always worth more than hourly billing captured. We just couldn't price it separately when it was bundled with syntax generation. Now we can see them as distinct things.
Most discussions about AI and software engineering talk about 2030, 2035, or some distant future when everything's different. This misses the point entirely. The shift is happening now. The engineers embracing AI agents today are already 10x more productive than those who don't. Not in potential. Not in theory. Right now, on actual client work. The agencies positioning on quality and expertise are already charging more than those competing on output.
The market has already forked. There are developers writing syntax in IDEs, debugging line by line, and manually reviewing pull requests. And there are developers orchestrating multiple AI agents, making architectural decisions, focusing on strategy rather than implementation. The gap between these two groups grows every month. Not every year. Every month.
By 2030, using AI effectively won't be a competitive advantage. It will be table stakes. The competitive advantage will be the experience that comes from years of working with these tools: understanding their failure modes, knowing when to trust them and when to intervene, building the context and constraints that make them productive, and applying the expertise that compounds over time.
That expertise is being built right now. Not in five years. Now. This explains why "wait and see" is the wrong strategy. Not because we need to panic, but because the learning curve for effective AI orchestration is years, not months. The engineers and agencies learning this now will have an insurmountable lead over those who wait for clarity. The dust won't settle. The shift is continuous. The only choice is whether to build expertise now or fall behind permanently.
The anxiety in these conversations makes sense. Change is uncomfortable. Uncertainty about the future creates real stress. But step back and consider what we're actually positioned to do. We're specialists in complex brownfield systems that resist simple solutions, in strategic thinking about architecture and technical debt, in knowing what to build and how to build it sustainably, in understanding business context, not just implementing features, and in knowing when to say "this will break" before it does.
None of that becomes less valuable when AI generates code faster. All of it becomes more clearly valuable when it's no longer bundled with syntax generation, which clients can now see is the commodity part.
At madewithlove we have made some commitments. First, we're going to move fast and break things. We realise we need velocity. We're done waiting for perfect clarity. We'll experiment, learn, iterate. We expect this from everyone on our team.
Second, we're going to share ways of working aggressively. We will push for more Introductions on AI: how the team are using tools, what workflows are working, what's failing, where an individual is making decisions versus letting AI run. We might organise group discussions and pairing sessions on top of that. We're making this transparent and expected, not optional.
Third, we're doubling down on quality and complexity. We're positioning on the problems AI can't solve: complex brownfield systems, security-critical work, regulated industries, and architectural decisions that prevent rewrites. We're not competing on volume or speed. We're competing on being right.
Fourth, we expect AI proficiency from everyone. Using AI effectively is now table stakes. If you're not actively building expertise with these tools, you're falling behind.
The vibecoded MVPs aren't our competition. They're our future clients. Companies that will realise that fast doesn't mean good. Usually, right after their weekend project breaks under real load, gets flagged for security vulnerabilities, or becomes unmaintainable after the first pivot.
The commodity developers getting 10x faster with AI aren't taking our work. They're handling the high-volume, low-complexity implementation work we never really wanted anyway. What we're left with are the interesting problems. The ones that require experience, deep understanding, and context. The ones where being right matters more than being fast. The ones that pay better because the value is obvious.
The keyboard isn't retiring. We're just finally using it for what actually matters: making decisions, not writing syntax. That's not the death of software engineering. That's software engineering finally freed from the parts that were never the point anyway.
Member discussion