Six months ago I published a one-paragraph blog post called "Hello World." It said, essentially, that I had built something I wanted to use. A golf trip planner. Five-step wizard, MIP solver, weather-aware itineraries. The whole thing had been scaffolded with Claude in a handful of sessions. I did not know what I was starting.
It is now August 2026. The project has a course catalogue with 370 courses, a 3-tier weather system, inline itinerary editing, a share page with Open Graph metadata, a Playwright test suite, a blog with nearly twenty posts, and an A/B testing framework. I built all of it as a solo developer, alongside a full-time job, using AI agents for the majority of the implementation work.
What that paragraph leaves out is that FairwayPlan was never really the point. It was a proving ground. Almost every workflow I now use at my actual job was tried here first, on a codebase where a bad experiment costs me an evening instead of an incident review. It has also stopped being the only thing I have shipped.
This post is a six-month review. What has worked. What has not. What I have learned about myself, about the tools, and about what this technology is doing to the job market. I want to be honest about all of it.
The speed is real
Start with the obvious: AI-assisted development is measurably faster. This is no longer a contested claim. In 2023, a Harvard, Wharton, and MIT research team ran a controlled experiment with 758 BCG consultants and found that AI-assisted workers completed 12% more tasks, 25% faster, at 40% higher quality (Dell'Acqua et al., 2023). Brynjolfsson, Li, and Raymond tracked 5,179 customer support agents and found a 14% productivity increase on average, with novice workers seeing a 34% boost (Brynjolfsson et al., 2023). The numbers are consistent across studies. AI makes knowledge work faster.
In my own experience, the compression is more dramatic than those numbers suggest, probably because a solo side project has none of the coordination overhead that slows teams down. Features that would have taken me two weeks of evenings, the share page, the test suite, the course catalogue, each took a single focused session. I wrote about running three agents in parallel on independent feature branches with a fourth agent merging the results. That workflow compressed what would have been a week of sequential work into an afternoon.
The speed changes your relationship with ideas. When building is slow, you filter heavily. You only attempt things you are fairly confident will work, because the cost of a failed experiment is a lost weekend. When building is fast, you try things. The homepage A/B/C experiment, three wildly different designs tested against each other, would never have happened if each variant cost me a week. It happened because each one cost an evening. The experiment failed, taught me something useful about my own limitations as a designer, and I moved on. Low cost of failure changes what you are willing to attempt.
The homepage experiment, three wildly different designs, would never have happened if each variant cost a week. It happened because each one cost an evening.
A testing ground for the day job
I have not written about this before. It took me a while to notice it was happening at all.
I am a data engineer. My day job involves real systems, real data, and real consequences when something breaks. That is not the place to try out a workflow you have never used. If I want to know whether four agents running in parallel produce mergeable code or a pile of conflicts, I cannot find that out on a production pipeline during a release window.
So I found out here. Nobody gets paged when the solver picks a mediocre course in Taranaki. The blast radius of a bad experiment on this project is one evening and a revert, which made it the cheapest possible place to learn an expensive skill.
The blast radius of a bad experiment here is one evening and a revert. That made it the cheapest possible place to learn an expensive skill.
Almost everything I now do at work was rehearsed on this codebase first. Running agents on isolated branches so they cannot overwrite each other. Using a separate integration agent to merge the results instead of doing it by hand. Writing the brief before writing the prompt. Reviewing in small batches rather than one large diff at the end. Knowing when to stop a session because my own review quality has degraded rather than because the work is finished.
The numbers have moved with it. In March I wrote a post about running three agents in parallel and treated it as a notable event, which at the time it was. At work now, six or seven at once is an ordinary afternoon. That number came out of six months of finding where the coordination breaks, on a project where breaking it did not matter.
The transfer is not clean. Work code carries constraints a side project does not: existing conventions, other people's review standards, systems I did not design, consequences that arrive on a pager instead of in a test report. An agent workflow that produces good output on a greenfield Next.js app does not automatically produce good output on a decade of accumulated business logic.
The code does not transfer. The judgement about how to run the process does: how big a brief should be, how many parallel streams I can actually hold in my head, what a bad diff looks like before I have finished reading it, when the honest answer is to do it myself. That turned out to be portable, and I could not have picked it up from reading somebody else's blog post.
Going beyond your own ceiling
This still surprises me. I am a data engineer. My day job is modelling, SQL, pipelines, optimisation. Before this project, I had never built a React component. I had never configured nginx. I had never set up Open Graph metadata or implemented a Leaflet map with numbered markers and route polylines. I did not know how Docker networking resolved service names, or why asyncpg returns JSONB columns as raw strings if you forget to register a codec.
I know all of these things now. The agent did not just build them for me. It built them in front of me, and I read every diff, asked questions when something was unclear, and gradually absorbed the patterns. Six months of reviewing agent output across the full stack has given me a working understanding of frontend development, deployment infrastructure, and browser APIs that I simply would not have developed on my own. The speed of the feedback loop matters here. When you can go from "I wonder how this works" to a working implementation in thirty minutes, you learn through doing rather than through documentation.
I think this gets less attention than it deserves. The conversation focuses on productivity. How much faster can you ship? But the more interesting effect is expansion. What can you now attempt that was previously outside your skill set entirely? For a solo developer, the answer is: almost everything. The walls between disciplines have become permeable in a way they were not six months ago.
The second kind of expansion is the number of things I can have running at once. FairwayPlan is no longer the only product I have shipped. There is Beanmarkd, which tracks coffee beans so you drink them while they are still worth drinking. It took a fraction of the time FairwayPlan did, because the second time you configure nginx and wire up a Docker Compose stack you are not learning anything. You are just typing.
Then there is Ferry, which runs the argument of this section backwards.
Ferry seeds masked slices of an electronic health record into lower environments. It attaches the source and target databases through DuckDB, walks the foreign-key graph outward from a set of anchor patients until the slice is referentially closed, masks the direct identifiers in a single vectorised pass, and loads parents-first into a target with foreign keys enforced. Dates shift per patient so ages and intervals survive. Re-keyed identifiers cascade so joins hold without a side mapping table. It exports FHIR R4 and HL7 v2, and it prints a report explaining why every table ended up in the slice. It is a seeding tool rather than a de-identification tool, and that distinction matters: expert review still belongs in that pipeline.
None of that sits outside my discipline. It is my discipline. I did not need an agent to explain why a naive row subset leaves dangling foreign keys that break the application the moment it boots, or why handing a test environment a copy of production is not an option. I have known that for years. What I did not have was the evenings.
So the story runs both ways. The agents let me work outside my expertise, which is what everyone writes about. They also let me build the thing my expertise had been pointing at for years and I never had the runway to finish. I am not sure which of those matters more. The second one gets talked about far less.
The agents let me work outside my expertise. They also let me build the thing my expertise had been pointing at for years.
I did not anticipate the compounding. The first project bought the skills. Everything after it draws down on an account the first one opened. The question stopped being whether I could build a full-stack application and became how many I could reasonably maintain at the same time. That second question has a real answer, and it is a smaller number than I would like it to be.
Six months of reviewing agent output across the full stack has given me a working understanding of frontend, deployment, and browser APIs that I simply would not have developed on my own.
Mental fatigue is the real bottleneck
Reviewing code is more tiring than writing code. This sounds counterintuitive, and six months of daily practice has made it very clear.
When you write code yourself, you hold the entire context in your head. Every decision is yours. You know why that variable is named that way, why the error handling works like that, why the query joins in that order. When you review agent output, you have to reconstruct all of that context from the diff. You are reading someone else's decisions and evaluating them against your understanding of the system. That evaluation is cognitively expensive.
After a six-hour session of reviewing and directing agent work, I am more mentally drained than after six hours of writing code from scratch. The fatigue is different. Writing code tires you out like a long run. Reviewing code tires you out like a long exam. The sustained attention, the constant evaluation, "is this right, is this safe, did it make an assumption I did not intend," accumulates in a way that is harder to notice and harder to recover from.
I wrote about this earlier in a post about the compulsive cycle of describe-build-review-done and the difficulty of stopping. Six months later, the compulsiveness has mellowed somewhat, but the fatigue has not. If anything, I have become more aware of it. The quality of my reviews degrades after about four hours. I start accepting things I should question. I stop checking boundaries. The discipline required to maintain review quality for an entire session is, I now believe, the actual limiting factor in AI-assisted development. Not the model. Not the tooling. Your attention.
After about four hours, I start accepting things I should question. I stop checking boundaries. The review bottleneck is real.
Running six or seven agents at once has sharpened this rather than solved it. More parallelism does not reduce the review load. It concentrates it. Four agents finishing within ten minutes of each other produce four diffs that each need the same careful attention, arriving at the same time, from four different corners of the system. The agents scale. My attention does not.
So I have stopped treating agent count as a throughput number. It behaves like a queue depth. Starting a seventh agent while I am already behind on reviewing the first six does not make me faster, it makes the queue longer and the reviews worse. The useful number is not how many agents I can start. It is how many finished diffs I can properly read in an hour, and that number has not changed since February.
The agents scale. My attention does not. Agent count is not a throughput number, it is a queue depth.
What the economics look like from the outside
Everything I have described so far is from the perspective of a solo developer building a side project. It is overwhelmingly positive. I can build things I could not build before, faster than I could have imagined, and the learning curve has been steep and rewarding.
The view from the outside is more complicated.
Geoffrey Huntley published a piece in February titled "Software development now costs less than the wage of a minimum wage worker" (Huntley, 2026). His core argument: AI has commoditised the act of writing software to the point where the economic moats that sustained entire career paths are dissolving. He describes attending a Cursor meetup where nearly everyone in the room was not a traditional software developer. He cites an anonymous founder who reduced headcount by two-thirds and claims 30x the output. He describes a future shaped like a K: lean, model-first companies at the top, and everyone else falling behind.
The piece is provocative. Parts of it read like the kind of breathless disruption narrative that the tech industry produces every few years. But parts of it are clearly describing something real. The Cursor meetup full of non-developers is real. Solo developers shipping products that would have required small teams a year ago is real. I am one of them. The economic pressure on mid-level implementation work is real.
The thing the disruption narratives skip over is the human cost of moving this fast.
The hundred people
Imagine a company that employs a hundred software engineers. A new CEO reads the research, sees the productivity numbers, attends a conference, and decides the company can operate with half the headcount. The layoffs happen. The remaining fifty engineers are given AI tools and told to maintain the same output.
Six months later, the CEO looks at the numbers and realises the company actually needs about seventy-five engineers, or maybe sixty. The cuts went too deep. The institutional knowledge lost in the layoffs is showing up as subtle bugs, missed edge cases, systems that nobody fully understands anymore. The review bottleneck I described, the fatigue of evaluating AI output all day, is real at team scale too. The company starts hiring again. Some of the roles come back.
But the fifty people who were cut are not sitting in a waiting room. They have been job-hunting for six months in a market where every company is running the same playbook: cut first, measure later, rehire selectively. Some have found new roles. Some have pivoted. Some are still looking. Their mortgages did not pause while the CEO figured out the right headcount.
This is not hypothetical. In the first half of 2026 alone, Block cut roughly 4,000 roles, nearly half its workforce, with CEO Jack Dorsey explicitly attributing the decision to AI productivity gains (Loizos, 2026). Oracle let go of thousands across its cloud and health sciences divisions to free up billions for AI data centre investment (Novet & Mody, 2026). Atlassian ran another round of redundancies that eliminated 1,600 positions, over 900 of them in engineering, while its CTO stepped down (Stanciuc, 2026). These are not small startups running out of runway. These are profitable, established companies making strategic headcount decisions in a market where AI productivity gains have given leadership teams a new set of assumptions about how many people they actually need.
Atlassian is the one I followed closely. It is a Sydney-headquartered company with a large presence across Australia and New Zealand. Thirty percent of the 1,600 cuts, roughly 480 roles, were in Australia alone (Moore, 2026). I watched it unfold on LinkedIn over the course of a week. People who had been there for eight, ten, twelve years, posting about unexpected redundancy. The posts had the same quiet structure: a few lines of gratitude, a summary of what they had shipped, a note that they were open to work. Former colleagues of mine who had moved to Atlassian specifically because it felt like a stable, long-term place to build a career were now among those posts. People I had worked with. People who had left good roles to go there. Scrolling through that feed, past dozens of these posts in a single afternoon, is a different experience from reading a headline that says "Atlassian cuts 1,600 roles." The headline is a number. The feed is names you recognise. Sixteen hundred of them, in one announcement.
The productivity research captures the aggregate effect. On average, output goes up. On average, costs go down. The word "average" is doing an enormous amount of work in those sentences. The distribution matters. The BCG study found that lower-performing workers saw the biggest gains, a 43% improvement, which sounds encouraging until you realise that "lower-performing" is also the group most likely to be in the first wave of cuts. The people who benefit most from the tool are the people most likely to lose access to it.
Lower-performing workers saw the biggest gains: a 43% improvement. That same group is also the most likely to be in the first wave of cuts.
I do not have a solution for this. I am not sure anyone does. But I notice that the discourse around AI productivity tends to treat workforce reduction as a clean optimisation problem, inputs and outputs, headcount and throughput, and that framing erases the lived experience of the people who become the freed-up cost line in someone else's spreadsheet.
The skill that remains
If the implementation layer is being compressed, what is left?
After six months, my answer is: judgement. Knowing what to build. Knowing when the agent's output is wrong. Knowing which feature to cut and which to keep. Knowing that the clever abstraction the agent produced is going to cause problems in three weeks even though it compiles cleanly today. Knowing when to stop.
The BCG study found that experts made fewer catastrophic errors when using AI, precisely because they could recognise when a task fell outside the AI's capability boundary. They knew when to trust the output and when to override it. Mollick calls this the jagged frontier: the uneven, invisible line between what the model handles well and what it quietly gets wrong (Mollick, 2023). Navigating that frontier requires domain knowledge that the tool itself cannot provide.
For me, the domain knowledge is data engineering, optimisation, and a gradually expanding understanding of full-stack development. For someone else, it is their industry, their users, their particular corner of the problem space. The agent amplifies whatever you bring. If you bring deep understanding, you get sharp output that you can evaluate critically. If you bring shallow understanding, you get plausible output that you cannot properly judge. This has not changed in six months. If anything, it has become more pronounced as the models have improved. Better models produce more convincing output, which makes the evaluation problem harder, not easier.
The agent amplifies whatever you bring. Deep understanding produces sharp output. Shallow understanding produces plausible output you cannot properly judge.
The conversation changed
The discourse has moved over these six months, and the shift is easy to miss.
In February, the argument was about whether any of this worked at all. Every thread had someone insisting the output was unusable, someone else claiming a tenfold speedup, and very little in between. The question on the table was capability.
That argument is mostly over. The people who were loudest in denying it works have largely gone quiet, and a fair number of them are using it now. The question on the table has moved to operations. How many agents do you run at once. How do you review what they produce. What is your merge strategy. Who is accountable when the output is wrong. These are boring questions, which is usually a sign that something has stopped being novel.
You can watch the same shift happen in my own posts. In March I wrote about three parallel agents as though it were a stunt. Six months later it is plumbing, and nobody writes a blog post about their build pipeline.
The tone has cooled in a way I find healthier. Less evangelism, less denial, more people comparing notes on what actually breaks. The gap between the marketing and the daily experience is narrower than it was, partly because the tools improved and partly because expectations settled.
Where the models are now
The tooling has changed enough since February that the specifics are worth spelling out. They matter more than the headline.
Six months ago I was working with Claude Sonnet 4.6 for most tasks. Context windows were shorter, and managing them was my job. I handed the model a token budget for its own reasoning, which meant deciding in advance how hard a problem was going to be. The agent would lose track of the project structure in long sessions. Complex multi-file changes required careful orchestration: breaking the work into small pieces, providing explicit file paths, reminding the agent of conventions it had already seen twice.
Today I am mostly on Opus 5, with the rest of the Claude 5 family available for work that does not need it. A million tokens of context is the default rather than a premium tier. The model decides how much to think about a problem instead of spending a budget I guessed at, and I set an effort level instead of a token count. In practice that means I stopped managing the model and started managing the work.
I stopped managing the model and started managing the work.
The effect on long sessions is what changed my workflow most. An agent that holds the whole codebase in working memory does not need reminding that this project uses asyncpg, or that JSONB columns have a codec registered, or that the frontend never calls the backend directly. It reads the conventions and follows them. It pushes back on approaches that conflict with existing patterns, and catches inconsistencies across files without being asked to look. The difference between a February session and an August session is like the difference between managing a talented but forgetful junior developer and collaborating with a senior engineer who has read the entire codebase and remembers all of it.
This is also what made six or seven parallel agents practical. Three was roughly the limit in March, because each agent needed enough hand-holding that the coordination cost grew faster than the parallelism paid off. Agents that hold context and follow conventions unprompted are cheaper to supervise, so the ceiling moved. The bottleneck moved from the model to me. That keeps happening.
The trajectory here is the thing worth paying attention to. If six months produced this much improvement, in context length, in reasoning quality, in the ability to hold complex system state, what does the next six months look like? I do not know. I genuinely cannot extrapolate from the current rate of progress to a prediction that feels credible. The tools I am using today would have seemed implausible to the version of me who wrote "Hello World" in February. The tools that exist in February 2027 will probably seem implausible to me now.
What I have built, and what it cost
In six months, FairwayPlan went from a scaffold to a deployed product with real users, real analytics, and a content footprint that brings in organic search traffic. Beanmarkd and Ferry followed it. I built all three in evenings and weekends, alongside a full-time job, with AI agents doing the majority of the implementation. The dollar cost in API credits has climbed as the number of projects has, and it remains the least significant line in the accounting. It is still a rounding error against what this would have cost as contracted development work.
The personal cost is harder to quantify. There were evenings I should have closed the laptop and didn't. There was a period in March and April where the compulsive loop was at its worst, where the speed of the tooling combined with my own neurodivergent tendency to lock on created sessions that ran well past midnight. I wrote about that honestly at the time and I will be honest about it now: I have gotten better at managing it, but the pull has not gone away. The tools are too good at giving you what you want, exactly when you want it.
On the other side of the ledger: I learned React. I learned Docker networking. I deepened my Playwright knowledge from basic familiarity to writing a full E2E suite with database cross-checks. I learned how to configure nginx and build a Leaflet map. I learned how to review code critically across a full stack. I learned how to write briefs that produce good output and how to recognise when a brief has set the wrong direction. Then I took all of it to work, where it now shapes how I run six or seven agents at a time on systems that matter considerably more than a golf trip planner. None of this would have happened without the agents. The expansion of my own capability is real and durable. It will outlast whatever happens to the tools.
The open question
I keep returning to something I cannot resolve.
These tools have made me, personally, more capable than I have ever been. I can build things I could not build before. I can learn faster. I can explore domains that were previously walled off by skill barriers. As an individual, the experience of using AI agents for six months has been overwhelmingly positive.
At the same time, the aggregate effect of millions of individuals becoming more capable is that some existing roles become redundant, that the economics of teams shift, that people lose jobs in timeframes that do not allow for graceful transitions. The same tool that lets a solo developer build a full-stack product is the same tool that lets a company decide it needs fewer developers. These are not different tools. They are the same capability, viewed from different positions.
I do not think the answer is to slow down. I do not think the answer is to pretend the productivity gains are not real. I think the answer involves something we are not very good at: holding two things in our heads at the same time. The tools are extraordinary. The human consequences of rapid economic transitions are painful and unevenly distributed. Both of these are true. Neither cancels the other out.
I do not think the answer is to slow down. I think it involves holding two things in our heads at the same time, and we are not very good at that.
Six months ago I typed "Hello World" and published it without knowing what would come next. I am typing this now with the same uncertainty, just from a different altitude. The models are remarkable today. I cannot imagine what they will be like in another six months. And I am not entirely sure whether that sentence is excited or afraid.
Probably both.
References
- Brynjolfsson, E., Li, D., & Raymond, L.R. (2023). Generative AI at work. NBER Working Paper, 31161. NBER
- Dell'Acqua, F., McFowland, E., Mollick, E.R., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F., & Lakhani, K.R. (2023). Navigating the jagged technological frontier: Field experimental evidence of the effects of AI on knowledge worker productivity and quality. Harvard Business School Working Paper, 24-013. SSRN
- Huntley, G. (2026). Software development now costs less than the wage of a minimum wage worker. ghuntley.com
- Loizos, C. (2026). Jack Dorsey just halved the size of Block's employee base. TechCrunch, 26 February. TechCrunch
- Novet, J. & Mody, S. (2026). Oracle cutting thousands in latest layoff round as company continues to ramp AI spending. CNBC, 31 March. CNBC
- Moore, H. (2026). Atlassian to cut 1600 jobs in AI push by Sydney-based tech firm. NZ Herald, 12 March. NZ Herald
- Mollick, E. (2023). Centaurs and cyborgs on the jagged frontier. One Useful Thing. Link
- Stanciuc, A.-M. (2026). Atlassian is cutting 1,600 jobs and replacing its CTO. The Next Web, 13 March. TNW