I Was Apprehensive
I was apprehensive about coding with AI.
I’ve been developing software for almost 30 years. My first code was BASIC on a Commodore 64, in the early ’80s. I was nine.
My first professional gig was in 1997, writing HTML files for DMV Headquarters in Sacramento, listing the locations of the field offices. By hand. Thousands of HTML files, every one of them edited manually and FTP’d manually. It was nuts.
Say the operating hours changed over the holidays. We’d get that request on paper. It would land in an inbox, the manager would assign it to someone, and that person would update the page. Then it got reviewed internally, we’d FTP it, and then we’d upload it to production by overwriting the HTML.
It was a ten-person department: one manager, seven coworkers, and two crazy students (I was one of them) who were already imagining a whole CMS before CMSs existed. This was 1997 and 1998, before FrontPage and Dreamweaver. I was experimenting with VBScript and Perl.
Quite hilarious how far we’ve come.
I think about that job every time an agent updates a dozen files in one sweep.
That’s what I was carrying into all of this.
I started using models in late 2023. It was novel, a game curiosity. I used it to get AI to write emails and do stuff, and to write a little bit of code. I’m still working at a bank as a software developer but it wasn’t as useful. It reminded me how CEO Sundar Pichai issued an internal code red and reshuffled multiple teams to respond to the existential threat AI chatbots posed to Google's core search and ad business. When I saw that news, ChatGPT couldn’t return data passed 2019. So that’s what you got. It made more sense later. So building with it? Hell no, lol. It really wasn’t in my purview. But then ChatGPT starting crawling the web and it was no longer poking around old archives of its training data. That’s when I started thinking: maybe this model can help me poke around some ideas I had for an app idea.
Validing The Idea
The idea for BenchBoard has been in my head for 7 years but I didn’t share the idea with OpenAI’s models until sometime in June of 2024. Just a few months after going through some trying times that I won’t get into. But that was the moment ChatGPT helped me with the planning and idea validation.
It was seven months of prompting this idea with the chatbot. Back and forth we went, asking what could be the issues, the market, the possible failures and eventually — the possibilties.
The understanding that this wasn’t just a simple idea. I was thinking of growing a platform and the idea would be the launchpad into what would ‘make it so’. Thank you Patrick Stewart.
The first prompt to write an HTML prototype didn’t happen until January 2025.
And that’s where the 21 months start.
The Superpower We Thought Was Ours
As is the case with most programmers, it felt like giving up learning how to code. It felt like giving up a long-time superpower that was exclusive to us developers. We felt special, needed, and had tremendous power over those who didn’t know how to code. We were also expensive.
I’m not the only one who felt it. Anthropic surveyed 132 of its own engineers and researchers and interviewed 53 of them. Some were worried about “skills atrophying as [they] delegate more.” One put it this way: “When producing output is so easy and fast, it gets harder and harder to actually take the time to learn something.” And some deliberately practice without AI. One engineer said, “Every once in a while, even if I know that Claude can nail a problem, I will not ask it to.” Anthropic makes Claude, so weigh that accordingly.
Gergely Orosz, who writes The Pragmatic Engineer, said it plainly in January: “There is grief involved for us developers, that’s for sure.” And then: “It feels like something valuable is being taken away, and suddenly.”
It isn’t only the famous names, either. Spend a little time in the developer forums and you’ll find working engineers describing the same feeling. AI hands you the first 80 percent almost for free, and that makes the last 20 percent, the polish that used to be the whole craft, feel enormous by comparison. The pressure is to accept good enough, because good enough is what everyone else is shipping. Some of them say it’s draining the joy out of the thing they loved doing.
The Abstraction Layer Keeps Going Up
Zoom out and this isn’t the first time the ground has moved. Programming has been climbing an abstraction ladder my whole career. Machine code gave way to assembly, assembly to C, FrontPage and Dreamweaver would write HTML code off WYSIWYGs, Visual Studio would autocomplete whole functions and methods, and those frameworks and libraries would do the plumbing for you. Every rung meant fewer people needed to know what was happening underneath, and every rung came with a round of “that’s not real programming.” The newest rung is the biggest jump, though — plain English. You describe what you want, and the code appears. How you describe it, though, is the big divider between good agentic developers and starters. More on that in Part 2.
If you’re encountering AI at your company right now and feeling anxious, that’s sensible. I’d be suspicious of anyone who wasn’t. It’s different this time for a reason I can see from where I sit: the earlier rungs changed how developers worked, and mostly stayed inside the developer’s world. This one doesn’t stay put. More and more trains are leaving the station, meaning AI is getting implemented in real companies, and it has a direct effect on how business gets done. It touches the people who sit next to the developers, too.
Companies Weren’t Shaped for This
Here’s the part that I think gets less attention. The way companies are organized today wasn’t designed for AI and LLMs. Roles, handoffs, approval chains and job titles were all built around humans doing each step, one at a time, with paper moving between desks. I know that world. See the DMV above. Many of those tasks are going to be displaced, and the shape of the organization will have to change with them.
You can already see the edges of it. In late October, Microsoft offered what it calls a “voluntary exit offer” to about 60,000 employees, roughly 27 percent of its global workforce, in the US, Canada, India and the UK. The reporting links it to the company’s accelerating AI spending, but it does not say AI is replacing those specific jobs, and I’m not going to claim that. What I will say is that a company of that size doesn’t make an offer like that lightly, and that it landed in the same news cycle as record AI investment.
What I can speak to firsthand is the small end of the scale. I’m watching these models change the way companies as small as mine work, and the way companies as big as my friends’ nine-to-fives work, overnight. Not over a decade. Overnight. It is crazy that we’re in this place, and in such a short time.
From what I’ve seen, a company that runs into this has roughly three ways to go. Some decide not to implement at all. They look at the risk, the cost or the discomfort, and keep doing it the old way. Some implement and let people go, and that’s the version you read about in the news. And then there’s a third path that almost nobody talks about.
I got to see that third one up close. I was brought in to help a department of about fifty people, inside a Fortune 500 company’s core infrastructure team, figure out how to start using AI models. Most of them kept fragile, multi-step data pipelines alive by hand: support tickets moving through text files, scripts, spreadsheets and APIs, with a person checking every step. About ten of them wanted to write code and weren’t allowed to. When I looked at the work honestly, I could see that a real adoption would replace a lot of those roles. I had made myself a rule not to hand over a plan that ended with my coworkers getting let go.
So we pointed the models at the right problems. Over about eight weeks, on site twice a week, I mostly answered questions and flagged risks like security, login flows and database design. Reviewers started writing code. Scripts went away and endpoints connected directly. Developers used the models to trace which changes would break other systems and to knock out repetitive refactoring, while keeping manual control of the core logic. People who had been stuck on documentation moved toward building components. Analysts moved to process improvements and self-service tools for other departments. Ideas that had been shelved for lack of time started coming back.
Nobody in that department lost a job while I was there, and two months after my contract ended, they were still hiring. I only heard that part secondhand, so I won’t oversell it.
I also want to be honest about how rare this is. It was one case. It happened to be the right place, at the right time, with the right consultant. The department head, who had been there about 35 years, retired within weeks, and I still don’t know whether that was his choice. A few people I’d met left or moved to other departments, and I never got a clear answer why. Layoff numbers also can’t show you the jobs a company never posts. So don’t read this as a trend. Read it as proof that the outcome isn’t fixed. I wrote the whole story in The AI Came for the Department. The Boss Left Instead. The short version: the model isn’t the variable. Who’s steering it is.
I Got Lucky With the Timing
There are plenty of developers right now who’ve spent years in nine-to-five jobs and feel stuck. They can see the shift. They aren’t sure how to get across it, and I don’t think that’s a failing on their part. It’s a hard spot to be in.
“I started to feel conflicted about giving advice, encouraging people to come into [software engineering] to get their foot in the door — when that very path started to crumble,” described James Cross of Downshift Design in a YouTube post. Previously a construction worker, Cross was self-taught and has been in software development for 14 years — 8 of which have been at a ‘large tech company’. Like Cross, many devs are describing this feeling similarly on social media, especially now with the way these models are leveling up.
I was lucky. I crossed over to agentic development gradually, while it was changing. Every step I took, the tools were only a step or two ahead of where I already stood: a chat window, then Codex, then an IDE, then Claude Code. I learned each rung as it appeared, and I built BenchBoard through all of it, so the habits grew alongside the tools. Nobody handed me the whole staircase at once.
That’s a different situation from someone who looks up today and finds that many trains have already left. The tools are better, which should make it easier, but the gap to cross is bigger, and there’s no gentle ramp. Getting people across it is the real challenge, and I don’t think “just learn to prompt” covers it.
The First To Go: Google and Stack Overflow
My first taste was OpenAI’s Codex, just as it launched around May 2025, but before that I was using SWE and Claude briefly to write code in the chat prompt. I’d ask questions about how to solve a syntax problem, an error code, or how to walk through a problem. It was something I used to do on Stack Overflow. I had a process for troubleshooting code. I knew what to do. It was exclusively our power as developers. We were the only ones who knew how to fix things. Prior to May 2025, the power was still in our court but I was already impressed with what the model was doing. If I came across your typical error codes, I would just paste it into Google and roll the dice hoping some website or Reddit post covered it. Stack Overflow was the next step, as I’d fire up a post and let the experts guide me. Once in awhile, I’ll poke around the manuals to see if I can get a code library to work properly and I’ll get it after a day of trying.
Sometime in 2024, it was at that point in time where I pasted the errors into ChatGPT and it did all the searching for me, grabbed what it thought were solutions on the internet and synthisized it into a single paragraph where it worked the first time.
“Very very cool,” I thought. Looking back, Sundar Pichai’s code red moment led to Gemini — which had nothing worthy enough for coding. He saw this moment coming and now Google is playing from behind.
Codex Got Me to July
OpenAI’s Codex impressed me with its prototypes and got me all the way to July with clickable, working prototypes. But it had so many problems with context, and so many problems putting together a cohesive set of entities. Codex was then breaking things unnecessarily. GPT would fire off a prompt, send things through git, fire up a VM in the cloud, and you’d be left watching your app crunch along in a command prompt. Zero IDE. Imagine that after every prompt, it has to fire up the VM, toil away at changes, all the while I’m just asking it to do a search and replace. It would take minutes to do things. Everything was done on the web. A lot of the heavy lifting was still done by me. I would still pull down the code, make changes locally, then push it up to GitHub, and Codex would do some work with it. While it was faster in some respects, I was still doing the heavy lifting.
Here’s the story from that stretch I’ll never forget. Codex looked at three screens, a roster view, a batting order, and a field diagram, and decided what the database should look like. Three screens, three tables: one for which players were active, one for the batting order, one for the defensive positions. It told me the schema was “expandable and would work perfectly over time.”
From a textbook, that’s a fine answer. Each concern is separated. Each table has a clear purpose. But I wasn’t building a homework assignment. I was building an app for a coach standing on a field in 95-degree heat, trying to swap two players before the umpire yells “Play ball.” Every change meant coordinating writes across three tables, and when one write landed and another didn’t, the batting order said a player was sixth while the roster said he was inactive. At one point I had 36 migration files for the defensive table alone.
It did not work perfectly over time.
On the calendar: Codex’s cloud agent launched around May 2025. Claude Code had launched as a research preview in February and went generally available that same month, alongside Claude Sonnet 4 and Claude Opus 4.
Enter Cursor, Windsurf, and a Shitload of Mistakes
At that time I was on Cursor, which was platform-agnostic. You can choose your favorite model. Again, just prompting my way through stuff. Then I went to Windsurf, which was just a cheaper IDE. Both IDEs had access to all models. I still had to spell things out. I was prompting each code change and reviewing each one. In some cases I would jump into the code myself just to save tokens, since they were the kind of changes that moved pixels around. I had access to all the models, and some used more tokens than others. SWE, Gemini, and Grok (half of which were token-free) would just fuck things up. So I stuck with switching between GPT-5 and the Claude models. I would still write up the functions, architect everything, and spell out some things, but I was already knee-deep in the fact that I was faster with these models in hand. They were not perfect. They still made a lot of mistakes, but I babysat through them and wrote the most detailed prompts and thought, “this is still a lot of work”.
But one thing I did appreciate in this part of the journey: I didn’t have to write the tests anymore. The AI did that, regardless of model. I remember spending hours doing that stuff. While there were plenty of developers who loved writing these things, I was one of those who felt like it was a bottleneck in doing the necessary things — product design.
On the calendar: GPT-5 arrived in August 2025 and Claude Sonnet 4.5 in September. In October, Cursor and Windsurf both shipped their own in-house models, Composer 1 and SWE-1.5.
At this point, I’ve spent a grand to prop up what looks close to being production-ready.
Claude Took Me to the Finish Line
Then it was Claude that did it for me. I heard it was better, and it had been doing code for over a year. I went with Claude Sonnet and was given the nod on simple things, but it was Claude that won it for me, and it took me to the finish line in early November 2025. It was perfect timing, as Opus was killer (more on that later). Keep in mind that I was selecting the model inside the IDE this whole time. As I freely selected between the models, I was still babysitting the model to make sure the code was written properly. I’d do the code reviews myself.
And while a ton of code was being generated, it was getting expensive. I spent a package of tokens on top of the $20 a month on just the Windsurf IDE, which has since been renamed Devin Desktop. I wasn’t sure if I’d stick with this one as the software was constantly changing. I’d already spent $300+ to increase my token balance as I was constantly prompting the IDE between several models. I found myself changing models just to save tokens on mundane tasks, but it would also mess up my context.
This one is an important notion to understand because it affected my workflow, and it became expensive. Switching between the models then relied on whatever was on the IDE. So if I switched from Gemini (which was free at the time) to Claude Sonnet (to do some serious work), the Claude API would have to grab everything that was prompted to generate the code and look at the code itself. I then realized why this was getting expensive — switching context.
On the calendar: Opus 4.1 had been out since August. Opus 4.5 was still a few weeks away.
After spending almost $1500 in tokens, I gave up on the middleman IDEs
At this point, this was when I gave the middleman IDEs a rest and went Claude Code all the way. That was December 2025 and January 2026. Claude Skills just came out in October of that year too, but I was just getting accustomed to developing the agentic way. MCP was still relatively new and models were slowly adopting it. I was still getting used to prompting like a programmer talking to a programmer. I was having a good time, as long as I babysat the model to completion of the tasks. At this point, I was “coding” 40% of the time. This means that if I spent 10 hours working on my project, 4 of those hours were spent doing things the old way: reviewing code, looking at the architecture, looking at how the code could be more efficient, etc. Staying DRY (Don’t Repeat Yourself) to make sure the model didn’t create new methods and properties that already existed. New versions of BenchBoard got out, and I was blown away by what I had built so far, but I felt there were still a lot of bottlenecks.
On the calendar, the AI companies were going nuts. Between November and December 2025, Christmas was upon us and their gifts just kept on coming. GPT-5.2 landed early in the month, Gemini 3 Flash later that month, and GPT-5.2-Codex a week after GPT-5.2. DeepSeek, Mistral and a few other ones made their way into the IDE for model selection, but I wasn’t impressed. They were all cheap with tokens — some of them didn’t charge any, but the models made a bigger mess on my codebase.
But the big one had to be Opus 4.5 — which was November. It was so huge because it became the first AI model to score over 80% on the SWE-bench verified coding test. It was the first time a model outscored human candidates on Anthropic’s internal engineering exam. And boy did I put it to the test. And even better, it delivered major jumps in token efficiency at a lower price.
Opus 4.5 changed software engineering
It was big for me as I saw the models level up in a way that changed the way I would do work. Forever. My hand coding went from 35-40% to just 5-10%. Yeah.
The moment where it left me in awe was when I asked it to refactor a huge chunk of code. It was the kind of refactor that was so necessary that the app would hit showstoppers after a certain point. I went through this last year. It was a combination of prompting and actual coding that got me through the first of many refactorings. I’ve even documented those moments. Some took a week or more.
Fast forward back to this moment. The prompt was at least seven to ten pages long, and it pulled it off successfully after a few prompts to clean up the errors.
What was even crazier was that the changes it suggested to the entities, with new migrations, were already in my mind. They were exactly the way I would have coded it by hand.
I was blown away.
The Noise
January 2026 is when the noise got loud. YouTube, Instagram and the rest of social media were suddenly full of wannabe AI reviewers hyping models that had no business anywhere near my codebase. By then BenchBoard was 400MB, which is pretty damn massive. This was no longer a small project. The QA guide I kept for it covered registration with email verification, MFA and reCAPTCHA, Stripe billing, Google Analytics, and an admin portal for managing organizations, leagues, divisions, seasons and games. Nobody testing a to-do app in a ten-minute video was testing anything like that.
More competition kept coming out. Kimi and a few others showed up, and I gave them a chance. On a codebase this big, it wasn’t worth switching models. Every switch costs context, and I had already learned that lesson the expensive way.
I also built smaller projects for clients with other models: bookkeeping, API integrations, accounting, tax processing. Those models were nowhere close in reasoning and logic once things got complicated.
Handing Off the Plumbing
Between July 2025 and about March 2026, I was still doing my own git commits and creating my own branches. In February I wrote a whole article about fighting .gitignore. By March, I had finally handed git to Claude.
CI/CD was the same story. I used to do the continuous integration, the continuous delivery and the tests myself. Now Claude handles all of it.
I also let Claude poke around in Hetzner and Coolify, the cloud provider and deployment tool that hold all my stuff. That is a long leash, and I know it.
Remote work changed too. Last year and earlier this year, I used TeamViewer to remote into my machine while traveling for clients and watching my kids’ games. Now I use Claude Remote Control, and it has been a huge godsend.
By now I’m fully in on Anthropic. Fable came out in June 2026, and that’s when I handed the refactoring to it. Most of my daily work is still Sonnet and Opus, though. Fable felt like overkill for everyday tasks.
I pushed back on Claude very often along the way, and I still do. The Azure story is the one I think about most. Just scroll to the section in that article titled “How Do I Know When the AI Is Wrong?”.
Now, I push back less and I’m making the leash longer. The model stays in context, and it hallucinates much less than it did a year ago. My prompts have changed too. They are essentially large documents now.
I wrote articles along the way documenting all of this, and some of them are already obsolete. That is how fast this has moved.
Am I Still a Programmer?
At some point, I started questioning my identity as a programmer. I’ve always remembered what coding was like, and how many layers of work it took. From DevOps, to database queries, stored procedures, frontend libraries, you name it. Now the machine was doing those layers in minutes.
Could a regular person do these very things I used to be hired for? What is the role of the software engineer now? Could a regular person talk to an LLM and accomplish the same things I’m doing with BenchBoard?
It wasn’t panic. It was more like: well, now what? This is how I remember doing work for such a long time, and I took pride in doing this type of work. And now I had a tool that does the heavy lifting. I stared at a wall for a while, lol.
How I Got Over It
It’s been months since I’ve done things the old way and it took awhile to shift my mind about how to operate with AI. My thought was “Anybody can do this now.”
Along the way, I saved hundreds (if not thousands) of my prompts as text files since Windsurf made it that easy to do at the time. I’m using Claude Code now but as I opened them up and re-read some of my old prompts, I also realized something.
### User Input [ME]
Nothing. Same result.
Here’s the thing it goes to:
benchboard-test-api.azurewebsites.net with a callback and state.
Is azure supposed to do something with that URL? It currently says “This page isn’t working right now” and “benchboard-test-api.azurewebsites.net can’t currently handle this request.”
Why? is it because Azure needs to perform an action? It’s also a 500 error.
Which is normally a server-side issue, meaning the problem lies with the server hosting the website, not with the browser, computer, or internet connection - or even cookie. Soo what’s your thoughts on that?
### Planner Response [Claude]
**You’re absolutely right!** 🎯 HTTP 500 = server crash, not a cookie issue. I’ve been chasing the wrong problem.
Let me check what’s ACTUALLY crashing on Azure. The issue is likely the **database** - either the connection or missing OAuth columns.
Now, if you’re not a software engineer, you’re not going to understand what was just happened. But if you are, you’ll be able to surmise from it.
That prompt I wrote couldn’t have been written by “anybody”. That’s when I realized that the abstraction layer, the layer where all the thinking occurs, still sits squarely in our courts. That prompt told me, “it looks like the AI still needs me”. I remembered it clearly too. ‘Anybody’ would’ve responded with…
### User Input
Why isn’t this damn thing working? Fix it!
And that person would still be stuck. Or worse, the AI will fix it in a way where it will blow up later. And that is the part I’ll delve deeply in Part 2. I believe it’s one of the many ways to help longtime programmers get through their mourning of their old ways quickly.
Perhaps, this calls for a new article but I digress.
The Next Step
I’d always envied how quickly the best senior engineers could type up code without making too many compile errors. They were my heroes. In the past, they mentored me and saved me from a bunch of problems. I considered myself good, just not great. But with this new power, I realized I could do more. I wasn’t just the guy with the shield. I knew how to use the suit and could stand side-by-side with the seniors doing what they could do.
So I tried something. I asked the model to do something difficult that I knew seniors could do: refactor complex classes, methods and endpoints by consolidating them. It made me wonder what I could do with this tool. Slowly, it made me realize I could do what the super senior devs could do.
What changed was imagination. I could now think of very complex UI ideas that I knew would take months to produce by hand, and now they could take weeks, if not days. What felt out of reach without these tools seemed possible now. Once I began writing up the prototypes and filling them with solid code through hardcore LLM driving, that’s what was accomplished.
The thought I keep coming back to: if we’re using models to get the work done, why not make it our best work, especially now that we have the time?
Staying grounded by remembering what we’ve done before.
This is one of myriad of things I used to Google all the time.
I had a bug where the drag overlay, the ghost of a player that follows your cursor, snapped to the top-left corner of the screen instead of tracking the mouse.
I told Claude to investigate with no code changes first, and it did genuinely deep work. It read the drag-and-drop library’s source, traced a timing race, and found a size mismatch between my overlay and the row it was copying. Then it offered me three ways to fix it, all of them keeping the table markup I already had.
I asked one question: would it be better to convert the table into a div?
Yes, it said. Better, actually, because the overlay is purely cosmetic.
The AI had optimized inside the box I handed it. Someone had to ask whether the box was the right shape. Again, ‘anybody’ couldn’t have known that. It was my early days of working at the DMV that knew this. Claude acknoledged that experience and gave the nod to a better way.
Think of two kinds of bosses.
The first one came up through the ranks. She’s fixed the printer, survived the 2 a.m. outage, and knows exactly which corner of the codebase is held together with duct tape, so when she says ‘that won’t work,’ the team listens, because she’s earned it. The second one arrived with a shiny master’s degree and a laminated org chart. He’s brilliant at slide decks and has never once seen the duct tape. The difference is that a team will quietly push back on him: a raised eyebrow, a ‘well, actually,’ a colleague who mutters ‘that’ll break production’ on the way to the coffee machine. AI has no eyebrow. It’s the most agreeable employee you’ll ever hire, and it will smile, nod, and cheerfully build whatever you ask for, even when you’re wrong. So when you aren’t an expert in the right way to do something, you’re the second boss, and nobody in the room is going to tell you.
What Still Had to Be Human
As of this writing, here is what still has to be me:
Product design
Business requirements
Audience analysis
Knowing what I really want in a product
Knowing how the product is supposed to operate
Small details
Intentionality
Designing: tech stack, code architecture, API, styling and UI animations
And here is what I have offloaded:
Tracking versions
Copying and Pasting Errors into the chatbot
Writing test cases
Simple but large-blast-radius refactoring
Quick prototyping and mockup creation
Implementation: animations, writing API endpoints, invoking API endpoints, UI and CSS, mobile implementation, installing plugins
Notice that animations show up on both lists. Here is the split. When I wanted a step-by-step wizard for entering the opposing team's lineup, I wrote the spec myself: which steps, what each button says, which columns drag and which don't (the position column drags by itself, vertically only). I also told the model not to wire it into the scorekeeper yet, because I wanted to test it on its own first.
For animation, I spelled out what happens when a ball is hit into the gap: four things start at the same time. The batter runs, the ball flies, the fielder chases it, and any runners already on base head halfway, very slowly. The model builds all of that. What it can't do is feel the pace. At one point we cut a single timing number by 31 percent, and the ball's travel time dropped 31 percent with it. The model's explanation was so full of jargon that I told it so, and it started over from the ground up. It laid out two fixes and ended by asking me which one I wanted. That is a question only I can answer, because the answer is how it feels on screen.
What I've Learned So Far
Design is human. Only humans can design. Intentionality is the big part.
Don't just make changes. Document them. Tell your model to document each change in the code as a comment, or in a separate MD file. Timestamp it. Your model should be able to tell you why you changed the color of a button or added a border to it, because one day you may want to change it back.
If you're adding a big feature, prototype it first. Don't code it directly into your codebase, even on a branch. Try it out yourself and watch how your audience would use it. See where the logic breaks or overlaps, and where the UI could be friendlier.
Make everything error-friendly. Give your audience a chance to understand what's wrong and how to correct it. A password meter that tells you which rule you missed beats "invalid password."
Tell your model to double-check its own work. You'll be surprised how many mistakes it finds on its second pass.
Give your audience a way to leave feedback, and tag it with the app version. Prompt the model for a feedback function and have it stamp the version automatically.
Collect all of your feedback in one place so your model can go through it and find the themes. This matters if you want your app to grow and avoid churn.
Enjoy the journey. Take rests.
Schedule your most productive hours to work with your model.
Where BenchBoard Stands Today
BenchBoard is live, in a beta season with a few hundred people, and I'm watching how it holds up when a real game is happening and a coach has one hand on a lineup card.
It is also where I paid for every lesson in this article: the three tables, the two players at right field, the AI announcing "found it" three times on three stacked bugs, and the one plain question that beat three clever fixes. None of that is about a specific language. It is 21 months of watching where an agent confidently goes wrong.
The tools got better, but the judgment is still ours. The model will build whatever you hand it with the same cheerful confidence, whether you are right or wrong, so the design, the intent, and the plain question that asks whether the box is the right shape have to come from you. Again…
The model isn’t the variable. Who’s steering it is.
And lately, something new has changed how I build. I just discovered loop prompting. More on that in Part 2.
Coming up in Part 2:
Loop prompting: efficient or token-wasting? Walking away vs. attending.
Boilerplating a design vs. designing it yourself
Cheating through scanned paper prototyping, and why paper prototyping matters even more now
It's still easy to make crappy code
Learning Remote Control on Claude Desktop
How my agentic skills helped me build my next app, BossFight, in 5 days
Sources: Gergely Orosz, “The grief when AI writes most of the code,” The Pragmatic Engineer, January 7, 2026 (blog.pragmaticengineer.com/the-grief-when-ai-writes-most-of-the-code). Microsoft’s voluntary exit offer per the Associated Press, October 26, 2026 (as carried by WDBJ7: wdbj7.com/2026/10/26/microsoft-offers-60000-employees-voluntary-buyouts-ai-spending-accelerates/). Anthropic engineer survey figures and quotes per Anthropic’s “How AI is transforming work at Anthropic,” December 2, 2025 (anthropic.com/research/how-ai-is-transforming-work-at-anthropic). Codex launch date per OpenAI’s “Introducing Codex” announcement. Windsurf’s rename per the Devin Desktop FAQ at docs.devin.ai. GPT-5.2 and GPT-5.2-Codex dates per BenchLM’s December 2025 release log. Other release dates per a separate AI research chat, not yet checked against primary announcements.
With all the onslaught of information, such workflows are to be placed down and to be changed. Along with outside the intelligentsia with the others labeling others as slop/banality peddlers and muting others, the most hostile coming from the commercial illustrators.
Thanks for the little data point. Going to get messy.