I Can Build Anything Now. I Have No Idea If That Counts.

"But they are useless. They can only give you answers."

Pablo Picasso, on computers, The Paris Review, 1964

For sixty years that line worked as a clean joke. Machines could calculate, they could not imagine, and the difference was obvious enough that nobody had to think about it very hard.

It has aged into something less comfortable. The answers are very good now. They arrive faster than I can evaluate them, in volumes I did not ask for, and most of the time they are correct. What Picasso left on the human side of the ledger was the question. That is now the entire job, and I have spent the past year trying to work out whether supplying the question is enough to count.

A year ago I could not ship software. Today I can build almost anything I can describe. The strange part is that those two sentences do not feel as far apart as they should.

The part where it works

The feeling starts somewhere around 11pm on a Tuesday. I have an idea for something that should exist, usually a system that removes a piece of manual work I am tired of doing. I open my terminal. I describe what I want. A few hours later there is a working thing running on a real URL with a real database behind it, and it does exactly what I wanted it to do.

This kept happening. Then it kept happening for bigger things.

Over the past year I have built outbound lead pipelines that source, enrich, score, and route businesses without me touching them. I have built the tooling around my own development environment so it runs the way I think. I have built the internal systems behind my independent applied AI R&D, including a CRM layer and the workflow orchestration underneath it, plus apps I use in my actual life every day. None of it is a toy. It runs. It handles real data. It breaks in real ways and I fix it.

At some point you stop asking whether you can build a thing and start asking whether the thing is worth building. That is supposed to be the good milestone. That is the one people talk about.

The part where I open the hood

The trouble started when I got curious.

I began reading the code more carefully instead of just confirming it worked. Not to debug it, just to understand it. And what I found was a system I could follow line by line, could explain to someone else, could tell you the purpose of every function in, and had not typed.

That is the split. I understand the architecture of everything I have shipped. I made the calls on how data moves through it, where state lives, what owns what, what happens when a step fails. I know why the queue is there. I know why that value gets passed instead of refetched. Those were my decisions and I would defend them.

I just did not write the characters.

And there is a voice that shows up right there and says: so what exactly did you do.

What I actually learned, which is more than I admit

Here is the thing I keep having to argue back with.

I did not start this year knowing what a race condition was. I did not know what idempotency meant, or why it mattered that a webhook might fire twice. I did not know what a migration was. I did not know the difference between a build error and a runtime error, or why environment variables behave differently in three places on the same platform. I did not know that most production bugs are not logic problems but shape problems, where the data arriving is not the data you assumed.

I know all of that now, and I did not learn it from a course. I learned it the way it actually sticks, which is by having something break at a bad time and needing it to not break again.

I can look at a proposed approach now and know it is wrong before running it. I can tell when a model is confidently building something overcomplicated. I can tell when it is quietly papering over a failure instead of handling it. That reflex did not exist twelve months ago. It is real knowledge and it was expensive to get.

So the honest accounting is: I learned a very large amount, and I still feel like I am standing on the first inch of something enormous. Both of those are true. Knowing more has mostly made the shape of what I do not know more visible.

The job description problem

This is where it gets uncomfortable in a practical way.

I read a job posting for an AI engineering role. Six months ago I would have skimmed past half the requirements without recognizing the words. Now I read the same posting and I understand every line of it. I have touched most of it. I have built things that would satisfy several of the bullets.

And I still hesitate on the apply button.

Because there is a difference between having built something and being able to build it under fluorescent lights with someone watching, from a blank file, with no assistance. I do not know which of those they are hiring for. I suspect they do not fully know either.

The same thing happens at work. An internal project comes down that needs software built and deployed, and I can do it, and I do do it, and it works, and the whole time a part of me is waiting for someone to ask a follow up question I cannot answer without opening a chat window first.

It happens with friends too. Someone asks what I have been building and I describe a multi-step agentic pipeline with fallback handling and human review gates, and they respond like I am an engineer, and I find myself adding a qualifier to the end of the sentence. I built it with AI. As if that were a disclaimer.

What I think is actually going on

I have landed somewhere on this, though not comfortably.

The imposter feeling assumes there is a real version of this skill that I am imitating. That the legitimate path is memorizing syntax and writing every line from scratch, and everything else is a costume. I do not think that holds up. Nobody is auditing whether a bridge engineer did the load calculations by hand. The question is whether the bridge holds.

What I am actually being tested on is judgment. Do I know what to build. Do I know when the thing in front of me is wrong. Do I know what done means, and what failure looks like, and where this breaks at ten times the volume. Do I own the outcome when it goes sideways at 2am. That part has never been automated for me. That part is entirely mine, and it is the part I have gotten measurably better at. Picasso had it right in the end. The answers turned out to be the cheap part.

But I want to be honest about the gap rather than reframe it away, because the reframe is too easy. There are things I would struggle with cold. Writing a nontrivial algorithm from memory on a whiteboard. Explaining the internals of a framework I use every day. Reading an unfamiliar codebase quickly without help. Those are real holes and pretending they are obsolete is how I would end up genuinely exposed later. The answer is to go fill them, slowly, in the background, while continuing to ship. Not to decide they do not matter.

Where I have landed

The imposter syndrome does not mean I am a fraud. It means I moved faster than my own sense of identity could keep up with. My capability jumped in about a year. My self concept is still running a year behind, checking credentials I do not have, against a definition of engineer that was written before the tools changed.

So I am doing the only thing that seems reasonable. I keep building. I keep opening the hood and reading what came out until less of it is a surprise. I apply to the thing I am not sure I am qualified for. I let the work be the evidence.

If I still feel like I am scratching the surface a year from now, that is probably a good sign. It means the surface got bigger, and I am still standing on it.