Tag: ai-assisted-development
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: api
Posts
HyperCrux 0.2.0 is out
A2 is done, and HyperCrux 0.2.0 is out. The new release setup published it automatically once the tests passed, without you clicking anything.
What 0.2.0 adds: hypercrux export writes a whole database as plain text lines, and hypercrux import reads them into a new file. Going in and out keeps every value exactly, and exporting the copy gives the same bytes as the original. The same export and import are available in Go.
Tag: app
Posts
HyperCrux 0.2.0 is out
A2 is done, and HyperCrux 0.2.0 is out. The new release setup published it automatically once the tests passed, without you clicking anything.
What 0.2.0 adds: hypercrux export writes a whole database as plain text lines, and hypercrux import reads them into a new file. Going in and out keeps every value exactly, and exporting the copy gives the same bytes as the original. The same export and import are available in Go.
Tag: architecture
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Tag: ceremonies
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Tag: code-quality
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Tag: code-review
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Tag: coding
Posts
HyperCrux 0.2.0 is out
A2 is done, and HyperCrux 0.2.0 is out. The new release setup published it automatically once the tests passed, without you clicking anything.
What 0.2.0 adds: hypercrux export writes a whole database as plain text lines, and hypercrux import reads them into a new file. Going in and out keeps every value exactly, and exporting the copy gives the same bytes as the original. The same export and import are available in Go.
Tag: coding-agents
Posts
VPN Works: Lets Agile Teams Run Coding Agents Safely Without Slowing Them Down
Security gates at the end of a sprint kill velocity. A coding agent can cut feature work time in half, but security teams that don’t understand what the agent does will block it. The agent reads code from your repo, issues from your tracker, snippets from web pages, and it writes back pull requests. One malicious instruction planted in that text can make the agent send a deploy token somewhere it shouldn’t.
Tag: continuous-delivery
Posts
BareProxy: An Agile Reverse Proxy That Explains Every Routing Decision
Teams shipping features fast need infrastructure that gets out of the way. The reverse proxy is supposed to be boring: TLS termination, serve static files, route traffic to the app, maybe some health checks. In practice, the config grows one regex at a time, until routing decisions become cargo cult superstition. Someone changed a block six months ago and nobody knows what would break if you moved it.
BareProxy is built on the insight that you can reason about routing only if you remove the things that are hard to reason about.
Posts
Preconfiguration: Solves the Setup Problem for Agile Teams Using Multiple Coding Agents
Every developer has lived the setup nightmare. You clone the repo, follow the README, get halfway through the steps, and something breaks. You Google the error, find three different solutions, apply the one that almost works, and spend two hours on an environment that everyone else on the team got right. Meanwhile, the new developer at the desk next to you is still stuck on step one. The setup is so fragile that nobody wants to change it, and it drifts from the reality of how the tests actually run.
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: contracts
Posts
Fixed Price Software Development: When It Works and When It Blows Up
A client asks for a fixed price. The vendor writes a spec, quotes a number, and both sides sign it feeling like they’ve eliminated risk. Six weeks in, the client wants a feature that wasn’t in the spec, the vendor calls it a change order, and the relationship that started as a handshake is now a negotiation over what “originally scoped” meant. That’s not a fixed price project gone wrong. That’s what most fixed price projects actually look like once real requirements meet a document written before anyone had built anything.
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Tag: databases
Posts
AltSql: Lets IoT Teams Ship Products That Work Offline and Sync Automatically
Teams building connected products face a design choice that kills agility: either the device depends on the server for everything, or you build a converter that keeps two data formats in sync. The device has readings and settings in its own format. The server wants those same values as SQL rows. Somebody writes a converter. Then somebody has to keep that converter alive and correct for ten years.
The converter approach is why IoT teams move slowly.
Posts
Precomputing: Keeps Dashboards Fast Without Slowing Development Cycles
Teams that ship features fast need dashboards that answer questions instantly. The usual pattern is to recalculate answers on every refresh, or to ship all your data to a hosted analytics service and wait for it to ingest. Both approaches have the same problem: the dashboard either waits for the query, or you pay for scale you don’t need most of the time. In either case, answering a question about your product becomes a friction point.
Tag: definition-of-done
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Tag: devops
Posts
BareProxy: An Agile Reverse Proxy That Explains Every Routing Decision
Teams shipping features fast need infrastructure that gets out of the way. The reverse proxy is supposed to be boring: TLS termination, serve static files, route traffic to the app, maybe some health checks. In practice, the config grows one regex at a time, until routing decisions become cargo cult superstition. Someone changed a block six months ago and nobody knows what would break if you moved it.
BareProxy is built on the insight that you can reason about routing only if you remove the things that are hard to reason about.
Posts
VPN Works: Lets Agile Teams Run Coding Agents Safely Without Slowing Them Down
Security gates at the end of a sprint kill velocity. A coding agent can cut feature work time in half, but security teams that don’t understand what the agent does will block it. The agent reads code from your repo, issues from your tracker, snippets from web pages, and it writes back pull requests. One malicious instruction planted in that text can make the agent send a deploy token somewhere it shouldn’t.
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: domain-name
Posts
HyperCrux 0.2.0 is out
A2 is done, and HyperCrux 0.2.0 is out. The new release setup published it automatically once the tests passed, without you clicking anything.
What 0.2.0 adds: hypercrux export writes a whole database as plain text lines, and hypercrux import reads them into a new file. Going in and out keeps every value exactly, and exporting the copy gives the same bytes as the original. The same export and import are available in Go.
Tag: engineering-culture
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Tag: engineering-leadership
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Tag: engineering-tools
Posts
AltSql: Lets IoT Teams Ship Products That Work Offline and Sync Automatically
Teams building connected products face a design choice that kills agility: either the device depends on the server for everything, or you build a converter that keeps two data formats in sync. The device has readings and settings in its own format. The server wants those same values as SQL rows. Somebody writes a converter. Then somebody has to keep that converter alive and correct for ten years.
The converter approach is why IoT teams move slowly.
Posts
BareProxy: An Agile Reverse Proxy That Explains Every Routing Decision
Teams shipping features fast need infrastructure that gets out of the way. The reverse proxy is supposed to be boring: TLS termination, serve static files, route traffic to the app, maybe some health checks. In practice, the config grows one regex at a time, until routing decisions become cargo cult superstition. Someone changed a block six months ago and nobody knows what would break if you moved it.
BareProxy is built on the insight that you can reason about routing only if you remove the things that are hard to reason about.
Posts
Precomputing: Keeps Dashboards Fast Without Slowing Development Cycles
Teams that ship features fast need dashboards that answer questions instantly. The usual pattern is to recalculate answers on every refresh, or to ship all your data to a hosted analytics service and wait for it to ingest. Both approaches have the same problem: the dashboard either waits for the query, or you pay for scale you don’t need most of the time. In either case, answering a question about your product becomes a friction point.
Posts
Preconfiguration: Solves the Setup Problem for Agile Teams Using Multiple Coding Agents
Every developer has lived the setup nightmare. You clone the repo, follow the README, get halfway through the steps, and something breaks. You Google the error, find three different solutions, apply the one that almost works, and spend two hours on an environment that everyone else on the team got right. Meanwhile, the new developer at the desk next to you is still stuck on step one. The setup is so fragile that nobody wants to change it, and it drifts from the reality of how the tests actually run.
Posts
VPN Works: Lets Agile Teams Run Coding Agents Safely Without Slowing Them Down
Security gates at the end of a sprint kill velocity. A coding agent can cut feature work time in half, but security teams that don’t understand what the agent does will block it. The agent reads code from your repo, issues from your tracker, snippets from web pages, and it writes back pull requests. One malicious instruction planted in that text can make the agent send a deploy token somewhere it shouldn’t.
Posts
Cloudflare's 50% Off GPT-5.6 Sol Promo Lands at OpenAI's Regular List Price
Cloudflare is promoting GPT-5.6 Sol through AI Gateway at what it calls half price, running through September 18, 2026. No promo code, no application. Point your requests at the gpt-5.6-sol model and the rate applies automatically.
The promo rates are $2 per million input tokens, $10 per million output tokens, and $0.25 per million cache read tokens. Cloudflare gives the regular rates as $4, $20, and $0.50.
Those numbers are worth holding up against the source.
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Tag: estimation
Posts
Fixed Price Software Development: When It Works and When It Blows Up
A client asks for a fixed price. The vendor writes a spec, quotes a number, and both sides sign it feeling like they’ve eliminated risk. Six weeks in, the client wants a feature that wasn’t in the spec, the vendor calls it a change order, and the relationship that started as a handshake is now a negotiation over what “originally scoped” meant. That’s not a fixed price project gone wrong. That’s what most fixed price projects actually look like once real requirements meet a document written before anyone had built anything.
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: kanban
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Tag: llm-costs
Posts
Cloudflare's 50% Off GPT-5.6 Sol Promo Lands at OpenAI's Regular List Price
Cloudflare is promoting GPT-5.6 Sol through AI Gateway at what it calls half price, running through September 18, 2026. No promo code, no application. Point your requests at the gpt-5.6-sol model and the rate applies automatically.
The promo rates are $2 per million input tokens, $10 per million output tokens, and $0.25 per million cache read tokens. Cloudflare gives the regular rates as $4, $20, and $0.50.
Those numbers are worth holding up against the source.
Tag: observability
Posts
Precomputing: Keeps Dashboards Fast Without Slowing Development Cycles
Teams that ship features fast need dashboards that answer questions instantly. The usual pattern is to recalculate answers on every refresh, or to ship all your data to a hosted analytics service and wait for it to ingest. Both approaches have the same problem: the dashboard either waits for the query, or you pay for scale you don’t need most of the time. In either case, answering a question about your product becomes a friction point.
Tag: product-backlog
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: projecr
Posts
HyperCrux 0.2.0 is out
A2 is done, and HyperCrux 0.2.0 is out. The new release setup published it automatically once the tests passed, without you clicking anything.
What 0.2.0 adds: hypercrux export writes a whole database as plain text lines, and hypercrux import reads them into a new file. Going in and out keeps every value exactly, and exporting the copy gives the same bytes as the original. The same export and import are available in Go.
Tag: prompt-engineering
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Tag: remote-teams
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Tag: requirements
Posts
Fixed Price Software Development: When It Works and When It Blows Up
A client asks for a fixed price. The vendor writes a spec, quotes a number, and both sides sign it feeling like they’ve eliminated risk. Six weeks in, the client wants a feature that wasn’t in the spec, the vendor calls it a change order, and the relationship that started as a handshake is now a negotiation over what “originally scoped” meant. That’s not a fixed price project gone wrong. That’s what most fixed price projects actually look like once real requirements meet a document written before anyone had built anything.
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: roles
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Tag: safe
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: scaling-agile
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: scrum
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: security
Posts
VPN Works: Lets Agile Teams Run Coding Agents Safely Without Slowing Them Down
Security gates at the end of a sprint kill velocity. A coding agent can cut feature work time in half, but security teams that don’t understand what the agent does will block it. The agent reads code from your repo, issues from your tracker, snippets from web pages, and it writes back pull requests. One malicious instruction planted in that text can make the agent send a deploy token somewhere it shouldn’t.
Tag: sprint-planning
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: team-dynamics
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Tag: team-structure
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: technical-debt
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Tag: testing
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Tag: user-stories
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: velocity
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.