Introduction

Last week, I built an app without writing a single line of code. It still feels slightly illegal to admit that out loud.

The IDE stitched most of it together. The agents filled in the logic. I spent my time describing what I needed — like guiding a very enthusiastic intern who occasionally rewrites your entire project because it “felt cleaner.”

And that’s when it hit me: developers aren’t disappearing — but what we do each day has already changed.

I’m not laying bricks anymore. I’m the architect who guides the builders. Less typing, more thinking. Less wrangling syntax, more designing boundaries.

Here’s what this new skill stack feels like in practice, with the real mistakes and odd surprises included.

The New Hard Skills: Orchestration & Specification

Intent Specification (Vibe Coding)

Last Tuesday, I said, “Make the login more secure.” The agent returned something that looked like a spaceship airlock. Beautiful, impenetrable, and completely unusable.

Agents are incredibly literal.

So now everything starts with mini-specs. Even buttons. I said, “Add a loading state to the submit button.” Returned: three new files, an animated SVG, and a dramatic full-page dimmer like the app was about to reveal plot-changing information.

What I wanted: a spinner, inside the button — nothing else.

So I rewrote it: “No new files. Spinner inline with the text. No overlays. Keep ARIA labels.”

Agents need boundaries. Without them, they get creative in ways that feel like asking someone to tidy your office and returning to find they’ve reorganised your entire personality.

Agentic Orchestration

Working with agents feels like leading a team where every member speaks a different dialect and nobody checks Slack.

I regularly talk to a Database Agent, a Security Agent, a UI Agent, and a Copywriting Agent who communicates exclusively in startup-launch energy. They don’t coordinate on their own. That’s my job.

Last month, Frontend Agent built a checkout flow. Meanwhile Database Agent stored addresses as {line1, line2} objects. Frontend expected a string. The site broke in production, and it was entirely my fault — not theirs.

We’re not writing implementations now. We’re writing the contracts between everyone involved. What shape is the data? What values are allowed? What happens on edge cases? It’s less “coding” and more “translating intentions.”

Verification Logic

Unit tests are adorable in this new world. They don’t help when your backend gets rewritten overnight by an optimistic agent who misunderstood a comment.

I’ve had to write verification scripts — tiny programs that constantly check: Can login still handle magic links? Did the summariser hallucinate anything? Has the “improved” sorter become unreasonably slow?

One memorable day, I changed a single comment in a file. The agent interpreted that as an invitation to regenerate the entire module. It stripped out validation, renamed variables, reorganised logic, and helpfully removed the security checks.

I caught it only because my eval script screamed.

We’re no longer just testing our code. We’re testing the agent’s reasoning — making sure it doesn’t quietly reinvent things we need to stay stable.

The Adult Skills: Auditing & Ethics

Some responsibilities can’t be delegated, no matter how clever the tool.

Energy Auditing

Model choice matters more than I expected.

A large reasoning model: 1 Wh per query.
A tiny local model: 0.02 Wh.

I once asked an agent, “Why isn’t this CSS selector working?” It spun up a large model, launched a headless browser, rendered the DOM, and analysed the layout tree.

It was a typo. I misspelt flex-direction.

It’s the equivalent of hiring a crane to move a teaspoon—it works, but it’s wildly unnecessary. Now I think about inference costs the same way I used to think about database efficiency.

Hallucination Forensics

Agents write “mostly correct” code. It runs. It almost does what you want. Then it quietly breaks something later.

A SQL query it generated worked perfectly in staging. In production, it dropped a column. The agent had inferred an outdated schema from an old document it found.

Debugging now is half tracing logic, half archaeology.
Why did it think formatPhoneNumber() existed?
Why did it insert a caching layer uninvited?

You’re not searching for missing semicolons. You’re reconstructing a thought process.

Compliance Integration

Our legal team introduced new rules last quarter:
No autonomous changes to customer data.
No unapproved permanent modifications.
Human sign-off required for anything destructive.

My automation agent scanned S3 and decided to “clean up unused buckets.” One of those buckets stored our annual compliance reports, which were accessed once a year.

I caught it in time. Now the rule is simple:
If deletion is involved, ask me.

I’m writing as many safeguards as I am features.

The Soft Skills: Taste & Systems Thinking

This is the part that remains deeply human.

Technical Taste

Yesterday, an agent gave me ten different login page designs: Neumorphic, Brutalist, Minimalist, Apple-inspired, Decorative animated, Corporate, Full-width, Modal, Retro terminal, and Card layout.

All technically correct. Only one is emotionally correct.

Taste is the muscle that helps you choose. It’s built by experience — doing, seeing, and noticing the things that don’t quite land. I’m still learning this every day.

System 2 Systems Thinking

Agents handle implementation. You hold the shape of the whole system.

I asked an agent to add a daily summary email feature. It did — flawlessly.
Except:

Our job queue maxes at 100 tasks
Scheduler is overloaded
API rate limits can’t handle the batch
Our billing tier doesn’t support the SMTP load

Nothing was “wrong” in the code. But the system couldn’t support it.

That gap — between correctness and feasibility — is human territory.
We’re learning to think one step wider, one layer deeper.

Putting It All Together: A Mini Scenario

My friend asked me to build a piano practice tracker.

Two years ago, I would’ve opened VS Code and started writing models.
This time, I started with the specification: What counts as practice? Recorded sessions? Scales? Daily summaries? Live feedback? No calendar integrations — they always break.

Then I set boundaries. Data stays local. No file modifications outside app/. No new dependencies without permission.

I assigned agent roles. UI Agent built screens. Logic Agent wrote streak calculations. Data Agent designed the schema. Summariser Agent drafted weekly recap emails.

I added safeguards. Confirm before deleting sessions. Ask before sending emails—never auto-update packages.

I wrote evaluation scripts. Does streak logic work with multiple practices? Does the UI behave on mobile? How does it handle timezones?

I used judgment. Friend prefers minimal interfaces, so I chose the clean design.

I did systems thinking. What if they switch devices? How much storage is needed? Can they export data? Will syncing create conflicts?

I didn’t “write the app.” I directed it — shaped it — and made sure nothing fell apart at the edges.

The work feels different now, but no less creative.

Summary Checklist

Old Skill	New Skill
Memorising syntax and APIs	Writing clear specs and boundaries
Unit tests for functions	Evaluation systems for agent behaviour
Optimising code speed	Optimising energy cost per inference
Finding missing semicolons	Understanding agent reasoning and assumptions

We’re not becoming obsolete. We’re evolving — toward clarity, judgment, creativity, and taste.

You should still learn to code. It makes everything easier to supervise. You catch problems earlier. And honestly? It’s still fun.

The New Skill Stack, from Writing Code to Managing Intelligence